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 14:11:26 +0200
  • Message-id: <1207829486.25732.54.camel@xxxxxxxxxxxxxx>
Dirk Mueller wrote:

I've looked at the current implementation of the branding policy in GNOME
related packages to see what needs to be done for KDE, and I stumble over
various issues:
should be up to date and mention all lower mentioned issues except:
- RPM and self conflict
- possible selecting unwanted supplementary packages to install
- old versions of branding
- branding comments discussion
- checkable rules
- desktop-data-SuSE

a) some packages (not all) Supplement branding-openSUSE

All should supplement it. If not, it is a bug.
Section "Defining correct version dependencies"

, some of them with the
version number 10.2, some with some other version number (some of them even
with the correct one). I figured already out that supplementing 10.2 is
pointless, but what is the other reason behind that?

Maybe it is a bad idea, but I used version the branding conforms. I
expect, that these packages will be reviewed, and artists will either
replace branding image to 11.0 one or say that the package is good
enough for 11.0. Until that, these packages don't fulfil the dependency.

Doesn't it mean that the
branding packages for GNOME will be installed in a pure KDE installation, or
vice versa.

It depends, whether libzypp will install supplementary packages
automatically, or only if dependencies are already selected.

In the first case, I should have to update specs and replace the plain
supplement by the packageand(foo: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

In addition it means that big parts of GNOME and KDE will be
installed for a minimal X installation, or a XFCE installation. What am I

b) the branding packages require the base packages,

No. It would cause dependency loop. But some of them may conflict with
old version of base package.
Again section "Defining correct version dependencies"

sometimes the base package
requires the branding package explicitely.

It should never require foo-branding-openSUSE or so. It may require meta
package foo-branding.

shouldn't it require some meta
package that can be provided by any branding implementation?

Optionally. It may require meta package foo-branding, if needed. Only
packages, which must have any branding package installed (e. g. splash
screen) to work correctly, need to require it.

Packages, which don't require branding package physically (e. g. missing
branding background may be replaced by solid color), don't need to
require it. If it exists, it will be installed using supplements, if
not, nothing will happen.

Section "Defining correct version dependencies", "If package can work
without any branding..."

c) why do branding packages require base packages? why do they require other

They should not require it. Which branding packages do it?

Well, logically they should. But it would cause dependency loop and
force foo and foo-branding-anyvendor into the same installation medium,
so the proposal does not contain it.

We will need another solution to remove obsolete branding packages. The
same problem will appear for obsolete shared library packages.

d) as we have this complicated construct with the version numbers based on
distro base version number, how does that add to the game of having to update
the versioning during a security update ?

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.

Security update don't allow to do major version update. If we will do
anyway, all branding artists will be forced to paint new splash screens

See section "Defining correct version dependencies".

the base package has to require an
updated version.

If programmers are smart enough to not include minor version number in
the artwork, then no.

can we add the versioning scheme to the policy (I think
something like 11.0.X, where X is the incompatibility counter during
maintenance updates and 11.0 is the distro base version).

It is there. Branding package contains something like incompatibility
counter. See "Branding packages version dependencies"

e) there was some parts in the wiki that mentioned that branding requirements
should be documented as comments alongside the sources in the spec file.
isn't there a better solution than that, like for example installing this
information alongside so that an actual branding editor can make use of this
information? or do we plan to rebuild source packages in the background?

Yes, it may be possible.

But it would introduce installation of many files not interesting to
ordinary users. As the branding design needs a work on RPM packaging
level, not having it installed may be not a big problem.

May intention was automatic extraction of all #BRAND comments after
OpenSUSE 11.0 release and putting all of the altogether somewhere to the
wiki. So the branding artist will have available complete list, not only
list for packages installed.

I plan to write a tool for it:
branding-comments-extract --rpm-sources=/media/SUSE1100.001

f) what about packages all desktops share (like e.g. the wallpapers in
desktop-data-SuSE)? do we have to copy them and maintain them in a
gnome-session-branding-openSUSE and kdebase4-workspace-branding-openSUSE ?

Rename it to desktop-data-branding-openSUSE or
desktop-branding-openSUSE, add branding symbols and require resolvable
desktop-data-branding or desktop-branding in relevant patterns.

g) what is the list of algorithmic checkable rules of this branding policy ?
believe that we need rpmlint checks for that, otherwise we'll never get it
right without a lot of testing.

Yes. But we should wait for first experiences. I am afraid, that some
parts of proposal may require update (see above).

Possible rules:
- foo-branding-vendor provides foo-branding
- foo-branding-vendor supplements branding-vendor
- foo-theme-vendor provides foo-theme
- foo-theme-vendor supplements branding-vendor
- foo-theme-vendor exists => resolvable foo exists
- foo-theme-vendor exists => resolvable theme-vendor exists
- foo requires foo-branding => #BRAND: comments are present

h) what to do about packages where the upstream package would be empty, or
where openSUSE is the upstream? should the branding-openSUSE package then
provide the upstream package?

Yes, it might be a good solution.

But, for example for SuSE specific /etc/gnome_defaults.conf in
glib2-branding-openSUSE I used a different solution:

glib2-branding-openSUSE prefers programs as we like

glib2-branding-upstream prefers only programs in the official GNOME

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 >