Dirk Mueller wrote:
Hi,
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:
http://en.opensuse.org/SUSE_Package_Conventions/Branding 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 foo-branding-*.
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 missing?
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 packages?
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 the 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 ASAP. 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 ? I 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 release -- 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