Dirk Mueller wrote:
On Thursday 10 April 2008, Stanislav Brabec wrote:
It depends, whether libzypp will install supplementary packages automatically, or only if dependencies are already selected.
if branding-openSUSE is installed, then all packages that supplement will be installed as well.
Then both proposal and packages already done need to move to packageand form. I'll prepare update and fixes.
In the first case, I should have to update specs and replace the plain supplement by the packageand(foo:branding-openSUSE).
where foo is.. ?
The name of the package, which should be branded. gimp-branding-openSUSE.spec: Supplements: packageand(gimp:branding-openSUSE)
There is also problem with proposed self conflict. It is ignored by libzypp, but it does not work in plain RPM. I don't know any other way, how to say, that foo-branding-openSUSE conflicts with all other foo-branding-*.
I think selfconflicts are not portable, and a strange concept. it would be possible to solve this via a file conflict, but this is ugly as well. I don't actually understand why they should conflict though (other than if they already do by installing conflicting files)? Yes, there are file conflicts by definition. I am perfectly OK to stay only at file conflicts. But I got a complain, that file conflicts are not ugly, and we should have package conflicts, probably because libzypp does not evaluate file conflicts and it could lead to installation errors.
I can imagine special handling in libzypp, if it will be required. If foo-branding-a and foo-branding-b conflict by definition, and it could be evaluated by libzypp implicitly.
wouldn't it be better to allow that somebody replaces just foo-branding-openSUSE with foo-branding-mySUSE without having to do anything else?
Yes, somebody could replace it easily. But we should have a proper solution for situation, where somebody wants gimp-branding-upstream: - Installation tool must (either automatically or on request) propose removing of conflicting gimp-branding-openSUSE - Installation tool must not force automatic replacing it back with gimp-branding-openSUSE, even if distro uses openSUSE brand, at least not in standard update mode. In system upgrade mode, it may propose such replacement.
We will need another solution to remove obsolete branding packages. The same problem will appear for obsolete shared library packages.
Hmm, in case the openSUSE branding is obsolete and we use the closedSUSE branding? I guess that can be solved by a plain obsoletes then.
Yes for this problem. But imagine that somebody will create openSUSE 11.0 based Flocke 11.0 and somebody will install it. Later, openSUSE 11.1 will be released and installed on top or Flocke 11.0. I do not see a way, how to prevent file conflicts.
Proposal explicitly talks about it. Dependencies are not strictly versioned. Base package may need new enough branding package, branding package conflicts with old incompatible base package.
but does not obsolete them?
No, gimp-branding-Flocke-2.4 has to conflict with gimp-2.2 (as it it does not provide correct image), but cannot obsolete gimp-2.2. It is a real life conflict, which must be raised by installation tool: gimp-branding-Flocke-2.4 conflicts with gimp-2.2. Proposed solutions: * remove gimp-branding-Flocke-2.4 and install gimp-branding-oldSUSE-2.2 And vice versa: OpenOffice-2.4 requires OpenOffice-branding-2.4, but installed package OpenOffice-branding-Flocke provides only version 2.2. Proposed solutions: * do not update OpenOffice to version 2.4 * remove package OpenOffice-branding-Flocke and install OpenOffice-branding-openSUSE version 2.4 -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org