El Sat, Oct 02, 2004 at 11:20:35AM -0500, Ian Murdock va escriure:
> Hi everyone,
Hi Ian,
> I've been meaning to get more involved in the CDD community, and this
> seems like a good way to introduce myself.
Good to see you on this list and better if is with this kind of questions.
> 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.
Yes, I believe that branding is something that all CDD can be interested
in and, at least in my case, we are.
> 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.
That's something we should try to change in Debian, IMHO it makes no sense
to be forced to create a binary package just because you need to change a
configuration or a data file.
> 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.)
Yes, but then you can't have two different brandings installed, and I see no
reason not to be able to do it.
Why not installing themes in their directory and have a configuration
variable that says to which directory must /usr/share/gdm/themes/default
point to?
> 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.
Well, of course we should try to have a solution to the *branding issue*
inside Debian, and maybe your approach can be implemented for some packages,
but in cases like gdm seems too complicated for me.
> 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.
I feel that the right solution is to make the gdm *brandable* using debconf,
simply adding a hidden question to change the default theme on /etc/gdm.conf
(it's default value can be whatever the debian maintainer likes), allowing
the CDDs and adminstrators to chage it using dpkg-reconfigure.
Using this mechanism you only have to install your theme and if you want it
to be the default you only have to pre-seed debconf with this value on the
CDD's installation system.
For already installed systems you can include a script in your branding
package to let the administrator change the debconf answers and
dpkg-reconfigure the affected packages.
In fact this kind of script can be writen to be used by all CDDs, simply
making it use configuration files included on the CDD branding packages,
probably installed in /usr/share/cdd/CDD_NAME/ and with optional changes
made by the administrator in /etc/cdd/CDD_NAME/.
> 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.
Well, I belive that the way to support branding depends on the configuration
systems in use; when it can be done changing values inside configuration
files of the packages, I would like to be able to do it using hidden debconf
questions.
This approach would be easily added into a lot of packages if we have a
standard way to apply debconf answers to configuration files (i.e. something
based on cfengine or similar tools that the package maintainer can call from
the postinstall script to apply debconf answers to the configuration).
This configuration files should be generated and handled by the postinstall
script, using configuration templates in /usr/share/ to generate the /etc/
files and ucf to preserver user changes (I have to review how ucf works, but
looks that it does the right thing for our needs).
When the branding only can be done changing data files maybe your current
aproach or an alternatives/diversion system could be the way to go
initially, remembering that on the long term the better aproach seems to be
change the program to make it more customizable using it's own configuration
files.
> Thoughts? How are other CDDs dealing with this?
Well, in our current **hackish** installation system we are diverting the
config files, but this is only for internal use, the plan is to use cfengine
scripts after installation to change the values that can not be set by
debconf pre-seeding.
We have done it this way because the diversion is fast to implement and will
allow us to upgrade to the right system more easily than other aproaches
without forcing us to recompile anything, next week we will see if I'm right
or not.
Greetings,
Sergio.
--
Sergio Talens-Oliag <sto@debian.org> <http://people.debian.org/~sto/>
Key fingerprint = 29DF 544F 1BD9 548C 8F15 86EF 6770 052B B8C1 FA69
Attachment:
signature.asc
Description: Digital signature