Mailinglist Archive: opensuse-packaging (111 mails)

< Previous Next >
Re: [opensuse-packaging] Questions regarding branding policy
  • From: Stanislav Brabec <sbrabec@xxxxxxx>
  • Date: Thu, 10 Apr 2008 18:17:16 +0200
  • Message-id: <1207844236.25732.96.camel@xxxxxxxxxxxxxx>
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.

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

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

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

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

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
* 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@xxxxxxx
Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747
190 00 Praha 9 fax: +420 284 028 951
Czech Republic

To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-packaging+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups