From version to version, package developers may decide to change sizes and types of images. On the other hand, it does not happen on every version update, and it is required not to force update of branding

Hallo. Here is a second candidate for distribution branding proposal. When there are no complains, I will start with creating example packages soon. Proposal: Distribution Branding / Branding-Enabled Packages Purpose of the Distribution Branding To provide a way to change the look of the distribution without rebuilding any of the binary packages at all, we need a way to provide package branding separately. These conventions should 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-opensuse*' should be empty on an openSUSE distribution) - 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 occurrences 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. Description of branding-enabled packages Branding-enabled packages provide its branding in 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 version dependencies. 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 "#BRAND: " 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 packages version dependencies Defining correct version dependencies package in such case. Suppose that version n has branding incompatible with previous version n-1 and the currect version is n+1, which is compatible with branding of n. Then dependencies should look as follows: foo.spec: Version: n+1 # Verify, that the branding package is new enough: Requires: foo-branding >= n foo-branding-myvendor.spec: Provides: foo-branding = %{version} # Do not allow to use this branding with incompatible old version: Conflicts: foo < n Package maintainer is responsible for choosing of correct versions. Note that not only upstream changes, but also packaging changes may introduce branding package incompatibility. 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: Version: 2.5 Requires: foo-branding >= 2.4 %package branding-upstream Supplements: branding-upstream Provides: foo-branding = 2.5 Conflicts: foo < 2.4 #BRAND: foo-splash.png: png or jpg file, 300x400 pixels. Progress bar #BRAND: will be displayed in lower 24 pixels. Image should include #BRAND: package name "FOO" and version letters "2.4". #BRAND: foo-info.png: Background of about dialog. Black names will #BRAND: appear in the light stripe in the centre. Branding package: foo-branding-myvendor.spec: Version: 2.5 Supplements: branding-myvendor Provides: foo-branding = 2.5 Conflicts: foo < 2.4 Branding virtual package or pattern provides resolvable branding-myvendor. Problems of branding bundles It is technically possible to create branding bundle packages from particular branding packages. But such bundles cause several important problems: - Branding bundle may lock users to exact version of some packages. - Possible security update which requires branding update will be hard blocked until update of the branding bundle. Possible branding related problems: Orphan branding packages Upper mentioned dependency scheme could cause orphan branding package, if user removes package itself. Possible solutions: - Adding of cyclic dependency to main package in the branding package. - Dedicated code in zypper. Partial branding and selecting package second-in-order Vendor can decide to provide only partial branding. It is not clean, which package from other available packages should be selected as second in order. Possible solution: - Repository order feature in incoming version of libzypp (note that it will not help for update repository with a set of additional brandings for more products). Partial branding and package replacement There is a possible problem when vendor has a limited set of branding packages and then wants to provide branding for a another package. In this moment, second-in-order branding is already installed. Possible solutins: - Use Obsoletes: foo-branding-second-in-order - Wait for distro update and use repository order feature in incoming version of libzypp -- 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