[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

custom branding and CDDs



Hi everyone,

I've been meaning to get more involved in the CDD community, and this
seems like a good way to introduce myself.

Progeny has a project called Componentized Linux
(http://componentizedlinux.org/) which aims to provide a toolkit for
builders of custom Debian distributions. Because CL is a toolkit, and
because one of the universal things a custom Debian distro wants to do
is supply its own branding, we provide a way for CL-based distro
developers to easily provide their own branding files
in a way that doesn't require forking any of the Debian packages.

Here's our current mechanism:

In cases where packages include branding (splash screens, background
images, themes, etc.) and where it's impossible to supply custom
branding by diverting a file or calling a tool (e.g., gconftool-2) in
the postinst, CL provides modified packages that use some default, known
value, rather than hardcoding the value. For example, we
have modified the gdm package to use a graphical greeter theme
called "default" rather than "circles", which the default gdm.conf
hardcodes and which cannot be diverted because it's a conffile.

To specify a theme, then, the custom distro builder supplies a package
that "Provides" and "Conflicts" with "cl-branding", which gdm (and other
packages that use this mechanism depend on to ensure some default
branding is present), and places the appropriate files in the
appropriate places. For example, the "progeny-branding" package (which
provides branding for Progeny Debian 2.0) installs its default
theme to /usr/share/gdm/themes/default. (The "Conflicts"
ensures that only one package can provide the "default" theme.)

So, in CL, a custom distro builder can change the gdm theme without
having to fork the gdm package. The CL infrastructure takes care of
providing a gdm package that understands the cl-branding mechanism,
and the maintainer of the gnome component takes care of making sure
the patch is applied to newer versions of the gdm package as it is
released.

Of course, I'd rather not have to fork any packages--it's a slippery
slope from which there's no escape (and this is speaking from
experience, as it's the approach we took with Progeny Debian 1.0).
Since this is almost certainly an issue with CDDs, could we work
together to come up with a custom branding mechanism that could be
merged into Debian proper post-sarge? That way, we could provide a
standard mechanism for supplying custom branding that works for
all CDDs and doesn't require any forking of packages to achieve it.

Note that I'm not wedded to the way we do it today in CL--I'm simply
outlining a solution that works for us. I'll be happy with any mechanism
to do this that doesn't require us to fork packages to implement it.

Note also that this is just another instance of the CDD configuration
problem (i.e., if we could provide our own gdm.conf without violating
Debian policy, the problem would be solved). Fortunately, we've been
able to solve most custom branding issues without having to resort to
this mechanism, but that may be because we've been dealing mostly with
Gnome, which provides an excellent infrastructure for decoupling the
software from the configuration via the gconf system. In the absence of
a new configuration framework that separates software from configuration
on a system-wide basis in Debian though, there will always be cases
where we'll have to deal with this issue, so I think we need to provide
a mechanism for doing things like this, at least in the medium term.

Thoughts? How are other CDDs dealing with this?

-- 
Ian Murdock
317-578-8882 (office)
http://www.progeny.com/
http://ianmurdock.com/

"A door is what a dog is perpetually on the wrong side of." --Ogden Nash




Reply to: