[opensuse-packaging] [RFC Proposal] Distribution Branding (packages)
Hallo. Here is a first draft of first part of proposal: creating of branding-enabled packages. More should come later. Proposal: Distribution Branding / Branding-Enabled Packages Description of branding-enabled packages Branding-enabled packages provide its branding is a separate package. This technique is useful for: - Providing custom branding images. - Providing custom default bookmarks. Rules for packaging of branding enabled packages - Branding image should exist in a separate file. - No custom branding images are added to the package. Package maintainer should split to two sub-packages - one with core files (foo) and one with branding provided by upstream (foo-branding-upstream). These packages are connected by branding virtuals. Conventions Package names All branding packages names should consist from three parts - package core name, string "-branding-" and the branding name. A special branding name is created by default: "upstream". This is a branding provided by upstream. Spec file comments Each file there should contain comment providing sufficient information for the artist. You can expect, that upstream branding will be available to the artist. Each line of these comment should start by "#ART: " string followed by these information: - Spec source file name (mandatory). Spec source package file name should be unique for the whole distribution. For example, if the target file name is /usr/share/foo/splash/image.png, source package file name should be foo-splash-image.png and it should be copied to the correct target in %install phase. - use case (mandatory, if it is not part of the file name itself, e. g. "about" - decoration of about dialog, "splash" - image displayed for a short time, when application is launching, "toolbar" - image in toolbar, "initial screen" - displayed when application is started before user starts to use it). - required art, if any (mandatory, if the image should contains program name letters, branch number, required logm comment should say, what exactly has to be included). - overlays, if any (mandatory, if the image is overlayed with any text in image, comment should say its size, color and position). - dependencies, if any (mandatory, if you can customize your look using another file, you must mention it). Examples: "Width of foo-img1.png must be the same as width of foo-bg.png." "You can define overlay text color, size and and position in splash.xml." - allowed file sizes (optional, if not present, artist has to follow upstream size). - allowed file formats (optional, if not present, artist has to follow upstream file format). - For branding of launcher icon it is preferred to create custom icon theme instead of branding. Branding virtual symbols Packager should create one virtual for each top-level file in the branding package (If the branding consists of an image, virtual should be relative to the image. If the branding consist from config or svg and related bitmap images, virtual should be relative to config or svg). Package maintainer is responsible for choosing of decent symbols. Requires and Provides should be no more strict than needed but must not be vague to allow bad branding. Use version based virtuals, if and only if the art itself contain version numbers. Examples: foo-splash-300x400 (splash is 300x400 in size) foo-splash-art_foo_2_4 (splash contains "FOO 2.4" letters art). Note to versioned branding symbols: If project uses per-branch branding, you cannot use versioned symbols (Provides: foo-splash = 2.4 will only complicate things, if it is designed to fit 2.4.1, using of foo-splash-art_2_4 is more appropriate). Branding supplement Each branding package should supplement branding vendor. It allows to choose correct branding package, if more branding packages are available. Branding supplement symbol constist of "branding-" string and symbolic name of the branding. Upstream branding symbolic name is "upstream". Example: Branding-enabled package: foo.spec: Requires: foo-splash-300x400-art_foo_2_4 Requires: foo-about-strip_middle-300x300 %package branding-upstream Supplements: branding-upstream #ART: foo-splash.png: png or jpg file, 300x400 pixels. Progress bar #ART: will be displayed in lower 24 pixels. Image should include #ART: package name "FOO" and version letters "2.4". Provides: foo-splash-300x400-art_foo_2_4 #ART: foo-info.png: Background of about dialog. Black names will #ART: appear in the light stripe in the centre. Provides: foo-about-strip_middle-300x300 Branding package: foo-branding-myvendor.spec: Supplements: branding-myvendor #ART: foo-splash.png: png or jpg file, 300x400 pixels. Progress bar #ART: will be displayed in lower 24 pixels. Image should include #ART: package name "FOO" and version letters "2.4". Provides: foo-splash-300x400-art_foo_2_4 #ART: foo-info.png: Background of about dialog. Black names will #ART: appear in the light stripe in the centre. Provides: foo-about-strip_middle-300x300 Branding virtual package or pattern provides resolvable branding-myvendor. -- 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
Stanislav Brabec
Hallo.
Here is a first draft of first part of proposal: creating of branding-enabled packages.
Let's give some background to the readers: This comes from the needs of building appliances and distributions where we need to change the look of the distribution but do not want to rebuild any of the binary packages at all. Therefore we need to create some conventions that allow the following: * Easy replacement of all branding contents * Figuring out which branding is used in a distribution to check that everything is properly branded (e.g. rpm -qa '*-branding*' |grep -v opensuse should be empty on an openSUSE distribution)
More should come later.
Let's add some usecases: * Joe likes to create his own distribution called "Flocke" on openSUSE and likes to replace everywhere the green SUSE geeko with a white polar bear. * Novell likes to release based on the openSUSE distribution their SUSE Linux Enterprise Server. Thorsten is tasked with changing all occurences of "openSUSE" with "SUSE Linux Enterprise Server". * Tara prefers the upstream branding of the various openSUSE projects and does not like to see openSUSE and Novell logos everywhere. She wants to change her system and replace the custom branding everything in an easy way. Please add more - and reformulate the above ;-)
Proposal: Distribution Branding / Branding-Enabled Packages
Description of branding-enabled packages
Please add which packages we have and what constitutes branding, e.g.: * Branding of artwork, e.g. desktop background, bootsplash, OpenOffice.Org startup logo * Branding of trademarked symbols, e.g. the SUSE geeko and openSUSE logo in the KDE kicker menu * Branding of default bookmarks, e.g. in Mozilla Firefox Andreas -- Andreas Jaeger, Director Platform / openSUSE, aj@suse.de SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Hello, the proposal sounds like a good idea, especially after reading AJ's usecases. I agree in most parts and have some technical stuff left: on Montag, 25. Februar 2008, Stanislav Brabec wrote: ...
Example:
Branding-enabled package:
foo.spec: Requires: foo-splash-300x400-art_foo_2_4 Requires: foo-about-strip_middle-300x300
Why not simply use foo-branding as (versioned) symbol and require / provide it? With symbols for every image, icon etc, some packages might end up with lots of symbols, which is not needed IMHO. Or do you really think some people will create branding packages which contain only parts of the package, like a package for foo-splash and another for foo-about-strip? I doubt ;-) (some time later) OK, got it - the problem is to make the dependencies both loose and tight enough - for example, artwork may be used for several versions of an application, but at some point in time an additional image might be added which is difficult to express as version number. [Please correct me if I'm wrong.] Two proposals: Please consider to use names starting with foo-branding for the symbols, for example foo-branding-splash-300x400-art_foo_2_4 to make it really clear what is meant (and to have another grep'able thing). You might also consider adding a way to find out if the branding package "just" contains freely distributable artwork or if it contains trademarks like the Novell logo which may not be used in custom distributions IIRC. quick idea: add a "Provides: trademarks" and people will be able to search for it using rpm --whatprovides. (There might be better solutions of course.) @AJ:
Please add which packages we have and what constitutes branding, e.g.:
Hint: http://en.opensuse.org/Rembrand (the tool should contain a list of artwork) and http://en.opensuse.org/Branding_Overview BTW: Do better/changed config files also count as branding? ;-) If so, you'll have some fun to compare /etc with the default config files of each package... Regards, Christian Boltz -- Ist doch ganz einfach. Windows arbeitet nach dem WYSIAS-Prinzip: What you see is Allgemeine Schutzverletzung! [Dieter Bruegmann in dag°] --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tue, 26 Feb 2008, Christian Boltz wrote:-
Please add which packages we have and what constitutes branding, e.g.:
Hint: http://en.opensuse.org/Rembrand (the tool should contain a list of artwork) and http://en.opensuse.org/Branding_Overview
It does. It has a list of packages with artwork that contains SUSE/Novell branding, and also where the images are considered to be optional, and allowed to be kept in a rebranded distribution, or are non-optional and have to be removed. The problem is, rembrand only lists the branded artwork in packages upto 10.2 being released. It presently doesn't have any details about branding in the KDE4 packages included with 10.3 or Factory. Finding new branded images is a slow and laborious process[0] of looking at each image, identifying which ones might be branded, and then checking more closely. So far, these are the new images that have SUSE/Novell branding: :arcad_eval-102:/opt/tuxbase/usr/textur/bitmaps/misc/SuSE_NOVELL_compiledfor.png :arcad_eval-102:/opt/tuxbase/usr/textur/bitmaps/misc/SuSE_NOVELL_compiledfor.xpm :arcad_eval-102:/opt/tuxbase/usr/textur/bitmaps/misc/SuSE_NOVELL.png :arcad_eval-102:/opt/tuxbase/usr/textur/bitmaps/misc/SuSE_NOVELL_Transparent.png :arcad_eval-102:/opt/tuxbase/usr/textur/bitmaps/misc/SuSE_NOVELL_Transparent.xpm :arcad_eval-102:/opt/tuxbase/usr/textur/bitmaps/misc/SuSE_NOVELL.xpm :fvwm2:/usr/share/X11/fvwm2/pixmaps/openSuSE.xpm :gau:/usr/share/gau/xpm/flag.xpm.0 :gau:/usr/share/gau/xpm/flag.xpm.1 :gau:/usr/share/gau/xpm/flag.xpm.2 :gau:/usr/share/gau/xpm/flag.xpm.3 :gau:/usr/share/gau/xpm/flag.xpm.4 :gau:/usr/share/gau/xpm/flag.xpm.5 :gfxboot:/usr/share/gfxboot/themes/NLD/back.jpg :gfxboot:/usr/share/gfxboot/themes/NLD/back-low.jpg :gfxboot:/usr/share/gfxboot/themes/NLD/welcome.jpg :gfxboot:/usr/share/gfxboot/themes/SLES/back.jpg :gfxboot:/usr/share/gfxboot/themes/SLES/back-low.jpg :gfxboot:/usr/share/gfxboot/themes/SLES/welcome.jpg :gfxboot:/usr/share/gfxboot/themes/SuSE/back-boot.jpg :gfxboot:/usr/share/gfxboot/themes/SuSE/back.jpg :gfxboot:/usr/share/gfxboot/themes/SuSE/phead.jpg :gfxboot:/usr/share/gfxboot/themes/SuSE/welcome.jpg :gfxboot:/usr/share/gfxboot/themes/Zen/back.jpg :gfxboot:/usr/share/gfxboot/themes/Zen/back-low.jpg :gfxboot:/usr/share/gfxboot/themes/Zen/welcome.jpg :gimp:/usr/share/gimp/2.0/images/gimp-logo.png :gimp:/usr/share/gimp/2.0/images/gimp-splash.png :gnome-desktop:/usr/share/pixmaps/gnome-suse.png o:kdebase4-workspace:/usr/share/kde4/apps/ksplash/Themes/Simple/Preview.png o:kdebase4-workspace:/usr/share/kde4/apps/kthememanager/themes/YellowOnBlue-big/YellowOnBlue-big.preview.png o:kdebase4-workspace:/usr/share/kde4/apps/kthememanager/themes/YellowOnBlue/YellowOnBlue.preview.png An 'o' before the first ':' means optional. As before, these are my guesses and may or may not be agreed upon by Novell legal. [0] It's taken me much longer to check the branding on the 10.3 packages than it did with the 10.2 packages, probably because I don't have anywhere near as much free time as I did then. So far I'm not even half way through the first DVD in the boxed set. Regards, David Bolt -- Team Acorn: http://www.distributed.net/ OGR-P2 @ ~100Mnodes RC5-72 @ ~15Mkeys SUSE 10.1 32bit | openSUSE 10.2 32bit | openSUSE 10.3 32bit | openSUSE 11.0a1 SUSE 10.1 64bit | openSUSE 10.2 64bit | openSUSE 10.3 64bit RISC OS 3.6 | TOS 4.02 | openSUSE 10.3 PPC | RISC OS 3.11 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
David Bolt
On Tue, 26 Feb 2008, Christian Boltz wrote:-
Please add which packages we have and what constitutes branding, e.g.:
Hint: http://en.opensuse.org/Rembrand (the tool should contain a list of artwork) and http://en.opensuse.org/Branding_Overview
It does. It has a list of packages with artwork that contains SUSE/Novell branding, and also where the images are considered to be optional, and allowed to be kept in a rebranded distribution, or are non-optional and have to be removed.
The problem is, rembrand only lists the branded artwork in packages upto 10.2 being released. It presently doesn't have any details about branding in the KDE4 packages included with 10.3 or Factory. Finding new branded images is a slow and laborious process[0] of looking at each image, identifying which ones might be branded, and then checking more closely.
Once the packaging proposal is done, it should be much easier to generate such a list since all branding stuff will be in separate packages. We'd like to have a solution that does not break rpm, Andreas -- Andreas Jaeger, Director Platform / openSUSE, aj@suse.de SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Hi, On Tue, Feb 26, Christian Boltz wrote:
on Montag, 25. Februar 2008, Stanislav Brabec wrote: ...
Example:
Branding-enabled package:
foo.spec: Requires: foo-splash-300x400-art_foo_2_4 Requires: foo-about-strip_middle-300x300
Why not simply use foo-branding as (versioned) symbol and require / provide it? With symbols for every image, icon etc, some packages might end up with lots of symbols, which is not needed IMHO. Or do you really think some people will create branding packages which contain only parts of the package, like a package for foo-splash and another for foo-about-strip? I doubt ;-)
(some time later)
OK, got it - the problem is to make the dependencies both loose and tight enough - for example, artwork may be used for several versions of an application, but at some point in time an additional image might be added which is difficult to express as version number. [Please correct me if I'm wrong.]
While this is a valid reason, I think the solution is not doable. As example use the YaST2 theme. Currently it has about 300 icons. Nobody is able to maintain 300 Provides and Requires correct. This is impossible to do. Instead I would go the following way: yast2-branding-openSUSE provides branding version 10.2. yast2-branding-openSUSE conflicts with yast2 < 10.2 yast2 will require yast2-branding >= 10.2 On openSUSE 10.3, the branding format hasn't changed, only the color of the icons. So the version number is increased, but the provides, conflicts and requires not. Everything will continue to work, on 10.3 you can use the old or the new artwork without problems. On openSUSE 11.0, the branding needs another format. So the branding version is bumped to 11.0, the conflict is changed to yast2 < 11.0, the requires is adjusted. I'm not sure if this branding version not equal to package version will really work in this way, here I need the comments of the rpm experts. There is another reason, why I wish to see an easier dependency solution than to provide/require every singe icon: Assume somebody wishes to provide a new branding for a special product. In this way, it is possible and maintainable, to provide the complete branding in only one RPM. I know that a lot of people would not like to let their customers download a huge bunch of different RPMs. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tue, 26 Feb 2008, Thorsten Kukuk wrote:- <snip>
Instead I would go the following way:
yast2-branding-openSUSE provides branding version 10.2. yast2-branding-openSUSE conflicts with yast2 < 10.2
yast2 will require yast2-branding >= 10.2
There's no need for this with versions before 11.0, unless YaST from 11.0 is going to be backported into the earlier versions.
On openSUSE 11.0, the branding needs another format. So the branding version is bumped to 11.0, the conflict is changed to yast2 < 11.0, the requires is adjusted.
I'm not sure if this branding version not equal to package version will really work in this way, here I need the comments of the rpm experts.
If I was designing the system, which thankfully I'm not, I'd probably go for something like: yast2 yast2-branding-openSUSE yast2-branding-SLES where the package yast2 contains all the un-branded artwork and have a requires for yast2-branding. The package yast2-branding-openSUSE and yast2-branding-SLES would provide the required branded artwork and then set Provides: yast2-branding in the spec file.
There is another reason, why I wish to see an easier dependency solution than to provide/require every singe icon: Assume somebody wishes to provide a new branding for a special product. In this way, it is possible and maintainable, to provide the complete branding in only one RPM. I know that a lot of people would not like to let their customers download a huge bunch of different RPMs.
That way has the benefits of havng all the brandng in one place, but it also means that there may be a very large part of included artwork in that package that isn't actually required by any other packages that are installed. Also, I think it would be easier to add another sub-package that includes all the branding for a particular package, than to move the branding into a central package. Regards, David Bolt -- Team Acorn: http://www.distributed.net/ OGR-P2 @ ~100Mnodes RC5-72 @ ~15Mkeys SUSE 10.1 32bit | openSUSE 10.2 32bit | openSUSE 10.3 32bit | openSUSE 11.0a1 SUSE 10.1 64bit | openSUSE 10.2 64bit | openSUSE 10.3 64bit RISC OS 3.6 | TOS 4.02 | openSUSE 10.3 PPC | RISC OS 3.11 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
David Bolt wrote:
On Tue, 26 Feb 2008, Thorsten Kukuk wrote:-
<snip>
Instead I would go the following way:
yast2-branding-openSUSE provides branding version 10.2. yast2-branding-openSUSE conflicts with yast2 < 10.2
yast2 will require yast2-branding >= 10.2
There's no need for this with versions before 11.0, unless YaST from 11.0 is going to be backported into the earlier versions.
This was just an example...
If I was designing the system, which thankfully I'm not, I'd probably go for something like:
yast2 yast2-branding-openSUSE yast2-branding-SLES
where the package yast2 contains all the un-branded artwork and have a requires for yast2-branding. The package yast2-branding-openSUSE and yast2-branding-SLES would provide the required branded artwork and then set Provides: yast2-branding in the spec file.
...why such a simple scheme isn't sufficient. There's no guarantee that a future yast2-branding will have the same format that today's yast2-branding. That's why some version information is needed, be it detailed as in Stanislav's proposal or just version numbers. Michal --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tue, Feb 26, David Bolt wrote:
There is another reason, why I wish to see an easier dependency solution than to provide/require every singe icon: Assume somebody wishes to provide a new branding for a special product. In this way, it is possible and maintainable, to provide the complete branding in only one RPM. I know that a lot of people would not like to let their customers download a huge bunch of different RPMs.
That way has the benefits of havng all the brandng in one place, but it also means that there may be a very large part of included artwork in that package that isn't actually required by any other packages that are installed.
Artwork is not that problem, but branding could also be a shared library or something similar. And in that case, you could get problems with dependencies.
Also, I think it would be easier to add another sub-package that includes all the branding for a particular package, than to move the branding into a central package.
For the initial creator of the distribution it is easier to add sub-packages, yes. But for somebody who wishes to provide a different branding for one special product, one RPM is simpler. So the solution should work with both situations. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On úterý 26 únor 2008, Thorsten Kukuk wrote:
Also, I think it would be easier to add another sub-package that includes all the branding for a particular package, than to move the branding into a central package.
For the initial creator of the distribution it is easier to add sub-packages, yes. But for somebody who wishes to provide a different branding for one special product, one RPM is simpler. So the solution should work with both situations.
One central RPM will either - make all updates of branding impossible or - need relatively complicated scripts to allow installation of multiple brandings in parallel IIRC it was decided on the dist meeting to keep it simple and use separate subpackages. Vladimir --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tue, Feb 26, Vladimir Nadvornik wrote:
On úterý 26 únor 2008, Thorsten Kukuk wrote:
Also, I think it would be easier to add another sub-package that includes all the branding for a particular package, than to move the branding into a central package.
For the initial creator of the distribution it is easier to add sub-packages, yes. But for somebody who wishes to provide a different branding for one special product, one RPM is simpler. So the solution should work with both situations.
One central RPM will either - make all updates of branding impossible or - need relatively complicated scripts to allow installation of multiple brandings in parallel
IIRC it was decided on the dist meeting to keep it simple and use separate subpackages.
Please read again what I wrote. For a distribution/distributor several separate subpackages are the right way to go. For a Redistributor of one product, one RPM is what customers expect. So a solution should allow to merge all sub-packages into one package, and currently all suggestions allow this. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tue, 26 Feb 2008, Michal Marek wrote:-
David Bolt wrote:
There's no need for this with versions before 11.0, unless YaST from 11.0 is going to be backported into the earlier versions.
This was just an example...
I know. I just followed along using it, but I'll use a generic version instead of yast2.
...why such a simple scheme isn't sufficient. There's no guarantee that a future yast2-branding will have the same format that today's yast2-branding. That's why some version information is needed, be it detailed as in Stanislav's proposal or just version numbers.
Okay, how about in the main package having: Requires: package-branding %version and the sub-packages: Provides: package-branding = %version This would seem to be the easiest system to use. Initially setting it up might take some effort, but it should be fairly easy to maintain afterwards. Of course, I could be missing something obvious. It certainly wouldn't be the first time. Regards, David Bolt -- Team Acorn: http://www.distributed.net/ OGR-P2 @ ~100Mnodes RC5-72 @ ~15Mkeys SUSE 10.1 32bit | openSUSE 10.2 32bit | openSUSE 10.3 32bit | openSUSE 11.0a1 SUSE 10.1 64bit | openSUSE 10.2 64bit | openSUSE 10.3 64bit RISC OS 3.6 | TOS 4.02 | openSUSE 10.3 PPC | RISC OS 3.11 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tue, 26 Feb 2008, Thorsten Kukuk wrote:-
On Tue, Feb 26, David Bolt wrote:
That way has the benefits of havng all the brandng in one place, but it also means that there may be a very large part of included artwork in that package that isn't actually required by any other packages that are installed.
Artwork is not that problem, but branding could also be a shared library or something similar. And in that case, you could get problems with dependencies.
I can see that. What I can't see is why there would be any branding in a shared library. The only reason I could see is that there's an embedded image included, and that's not a good idea if you're wanting to allow for re-branding. Regards, David Bolt -- Team Acorn: http://www.distributed.net/ OGR-P2 @ ~100Mnodes RC5-72 @ ~15Mkeys SUSE 10.1 32bit | openSUSE 10.2 32bit | openSUSE 10.3 32bit | openSUSE 11.0a1 SUSE 10.1 64bit | openSUSE 10.2 64bit | openSUSE 10.3 64bit RISC OS 3.6 | TOS 4.02 | openSUSE 10.3 PPC | RISC OS 3.11 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tue, Feb 26, David Bolt wrote:
I can see that. What I can't see is why there would be any branding in a shared library. The only reason I could see is that there's an embedded image included, and that's not a good idea if you're wanting to allow for re-branding.
Maybe your application is having an animated splash screen, which is drawn by code and not delivered as image? I don't know if we still have such applications, but I know in the past we had. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tue, 26 Feb 2008, Thorsten Kukuk wrote:-
On Tue, Feb 26, Vladimir Nadvornik wrote:
One central RPM will either - make all updates of branding impossible or - need relatively complicated scripts to allow installation of multiple brandings in parallel
IIRC it was decided on the dist meeting to keep it simple and use separate subpackages.
Please read again what I wrote. For a distribution/distributor several separate subpackages are the right way to go. For a Redistributor of one product, one RPM is what customers expect.
I'm not sure there's a distinction. From the point of view of a customer of the re-distributor, they are the distributor, just as SUSE/Novell are for their present customers. Are these customers really going to notice several small packages that, by looking at the package names, have something to do with the package they are branding? Or are they going to notice a very much larger package, one that may or may not have anything to do with the ones they're installing? My guess is that, if the packages were distributed on physical media, they aren't going to notice either. If the packages are being downloaded individually, they're much more likely to notice a single package rather than several smaller packages, especially since the larger package will be larger than all the small ones. Finally, if there is a goal of reducing the footprint of the installation, having one RPM that contains the branding for every package is going in the opposite direction. One big RPM is going to contain branding for packages that aren't installed, where multiple branding packages won't. Regards, David Bolt -- Team Acorn: http://www.distributed.net/ OGR-P2 @ ~100Mnodes RC5-72 @ ~15Mkeys SUSE 10.1 32bit | openSUSE 10.2 32bit | openSUSE 10.3 32bit | openSUSE 11.0a1 SUSE 10.1 64bit | openSUSE 10.2 64bit | openSUSE 10.3 64bit RISC OS 3.6 | TOS 4.02 | openSUSE 10.3 PPC | RISC OS 3.11 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tue, 26 Feb 2008, Thorsten Kukuk wrote:-
On Tue, Feb 26, David Bolt wrote:
I can see that. What I can't see is why there would be any branding in a shared library. The only reason I could see is that there's an embedded image included, and that's not a good idea if you're wanting to allow for re-branding.
Maybe your application is having an animated splash screen, which is drawn by code and not delivered as image?
I don't know if we still have such applications, but I know in the past we had.
I know. When I was experimenting with rembrand, and demonstrating how easy creating a de-branded installation could be, I found that xdm displays one that was embedded in /usr/bin/BackGround (xdmbgrd). As it was embedded, it was quite difficult to remove that image without either a recompilation or replacing /usr/bin/BackGround with a script that just returned an exit code of 0. Regards, David Bolt -- Team Acorn: http://www.distributed.net/ OGR-P2 @ ~100Mnodes RC5-72 @ ~15Mkeys SUSE 10.1 32bit | openSUSE 10.2 32bit | openSUSE 10.3 32bit | openSUSE 11.0a1 SUSE 10.1 64bit | openSUSE 10.2 64bit | openSUSE 10.3 64bit RISC OS 3.6 | TOS 4.02 | openSUSE 10.3 PPC | RISC OS 3.11 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
David Bolt
On Tue, 26 Feb 2008, Thorsten Kukuk wrote:-
On Tue, Feb 26, Vladimir Nadvornik wrote:
One central RPM will either - make all updates of branding impossible or - need relatively complicated scripts to allow installation of multiple brandings in parallel
IIRC it was decided on the dist meeting to keep it simple and use separate subpackages.
Please read again what I wrote. For a distribution/distributor several separate subpackages are the right way to go. For a Redistributor of one product, one RPM is what customers expect.
I'm not sure there's a distinction. From the point of view of a customer of the re-distributor, they are the distributor, just as SUSE/Novell are for their present customers.
The use case is here that a company likes to create their own custom branding. For them it's easier to put all branding in one single RPM and supply that instead of building let's say 10+ different packages with e.g. two files in each. For us as distributor with different people working on different packages, it makes sense to split them up. But for somebody that wants to change all branding, a single RPM might make more sense. And if I understand Thorsten correctly, all he asks is that a single RPM is an option for a replacement branding - it's then up to the development team what is more convenient to them, Andreas -- Andreas Jaeger, Director Platform / openSUSE, aj@suse.de SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Andreas Jaeger wrote:
Please read again what I wrote. For a distribution/distributor several separate subpackages are the right way to go. For a Redistributor of one product, one RPM is what customers expect.
I'm not sure there's a distinction. From the point of view of a customer of the re-distributor, they are the distributor, just as SUSE/Novell are for their present customers.
The use case is here that a company likes to create their own custom branding. For them it's easier to put all branding in one single RPM and supply that instead of building let's say 10+ different packages with e.g. two files in each.
For us as distributor with different people working on different packages, it makes sense to split them up. But for somebody that wants to change all branding, a single RPM might make more sense.
Imagine a security version update. New version may require branding update. All available updated (standalone) branding packages conflict with redistributor's bundle. It implies, that security update may trigger immediate action needed from the redistributor: update of the branding bundle. Without bundles, redistributor action is still required, but missing branding will not hard-block security update.
And if I understand Thorsten correctly, all he asks is that a single RPM is an option for a replacement branding - it's then up to the development team what is more convenient to them,
My current proposal + bundles makes mentioned problem blocker. Separate packages or more complicated proposals (patched source, symlinks) could allow to work-around this with a sub-optimal way: temporary picking of alternative branding. -- 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
Very interesting Idea indeed ! -- -Alexey Eremenko "Technologov" --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Thorsten Kukuk wrote:
Instead I would go the following way:
yast2-branding-openSUSE provides branding version 10.2. yast2-branding-openSUSE conflicts with yast2 < 10.2
yast2 will require yast2-branding >= 10.2
Yes, it looks possible, as we know lowest version compatible with the current branding, and when future version will be released, we will know the highest version not suitable for current design. I see a downside of this (and my proposal as well): Removing foo will keep foo-branding-openSUSE installed without use Maybe cyclic dependency may be OK here. (for non-bundled branding packages) -- 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
On Tue, Feb 26, Stanislav Brabec wrote:
Andreas Jaeger wrote:
Please read again what I wrote. For a distribution/distributor several separate subpackages are the right way to go. For a Redistributor of one product, one RPM is what customers expect.
I'm not sure there's a distinction. From the point of view of a customer of the re-distributor, they are the distributor, just as SUSE/Novell are for their present customers.
The use case is here that a company likes to create their own custom branding. For them it's easier to put all branding in one single RPM and supply that instead of building let's say 10+ different packages with e.g. two files in each.
For us as distributor with different people working on different packages, it makes sense to split them up. But for somebody that wants to change all branding, a single RPM might make more sense.
Imagine a security version update. New version may require branding update.
That's a nogo for a Enterprise distribution.
All available updated (standalone) branding packages conflict with redistributor's bundle.
It implies, that security update may trigger immediate action needed from the redistributor: update of the branding bundle.
Without bundles, redistributor action is still required, but missing branding will not hard-block security update.
Depending on trademarks, contracts or so, it will hard-block a security update. Especially the trademark problematic can lead to big problems even on openSUSE. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On úterý 26 únor 2008, Thorsten Kukuk wrote:
Imagine a security version update. New version may require branding update.
That's a nogo for a Enterprise distribution.
Yes, but IMHO we should still make it technically possible.
All available updated (standalone) branding packages conflict with redistributor's bundle.
It implies, that security update may trigger immediate action needed from the redistributor: update of the branding bundle.
Without bundles, redistributor action is still required, but missing branding will not hard-block security update.
Depending on trademarks, contracts or so, it will hard-block a security update.
Especially the trademark problematic can lead to big problems even on openSUSE.
I can imagine situations where upstream branding is temporarily used till the redistributor fixes the branding packages. I thing that we should document that the bundles are possible, however the redistributor must be prepared to handle the issues mentioned above. Vladimir --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
participants (8)
-
Alexey Eremenko -
Andreas Jaeger -
Christian Boltz -
David Bolt -
Michal Marek -
Stanislav Brabec -
Thorsten Kukuk -
Vladimir Nadvornik