Mailinglist Archive: opensuse-packaging (139 mails)
| < Previous | Next > |
[opensuse-packaging] [RFC] Proposal: Distribution Branding (RC2)
- From: Stanislav Brabec <sbrabec@xxxxxxx>
- Date: Mon, 03 Mar 2008 15:34:29 +0100
- Message-id: <1204554869.5725.62.camel@xxxxxxxxxxxxxx>
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
version update, and it is required not to force update of branding
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@xxxxxxx
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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-packaging+help@xxxxxxxxxxxx
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
From version to version, package developers may decide to change sizesand 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
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@xxxxxxx
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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-packaging+help@xxxxxxxxxxxx
| < Previous | Next > |