Re: custom branding and CDDs
On Sun, 03 Oct 2004, Ian Murdock wrote:
> > 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.
> I like it.
>
> By the way, if we're going to extend gdm to support debconf
> configuration, there are two more variables I found last night that
> influence branding: BackgroundColor, which is the background color shown
> as the login splash screen is displayed (we want to change the color
> to better match the login splash image); and GtkRC and GtkTheme, which
> is the theme used by the windows GDM creates to change language etc.).
This issue has been a central one to all CDDs, and we have all come to
the conclusion that we can use either debconf preseeding, cfengine,
hand-written scripts or use configuration files that do diversions.
The discussion has always been, which one of these fits within Debian
policy so that it is "the right way"(tm).
None of these options are particularly good, in my opinion, but I dont
have an alternative, but I think that if CDDs are going to go down the
route of debconf preseeding, and we are going to start to pester
package maintainers to include low-pri debconf questions, and we are
going to try and push for a policy change, then we really need to
think how this concept will logically extend into the future and if it
makes sense.
I think branding, when it comes to icons, themes, backgrounds, etc.
can be done relatively gracefully with debconf preseeding as was
outlined above. However, as more variables are uncovered that people
want to brand, and as CDDs drift from branding the graphical, to
"branding" a configuration file so that the software works a
particular way with specific variables set, then debconf preseeding
becomes a package maintainer's nightmare. Can you imagine creating
low-priority debconf questions for every possible postfix
configuration variable and then having to maintain that for every new
version of postfix? What about amavis that seems to have thousands of
variables? At some point the package maintainer is not going to be
happy with all this extra work. Does it make sense to abstract all
package's configuration variables into debconf? Can debconf handle it?
Should we be thinking of another way to abstract configuration?
If the user is running a CDD, how will they deal with updating
packages? What if a package has a new configuration variable, or an
old one changes or becomes removed, or one variable changes that
messes up another that was preseeded? Will they have to wait for the
CDD-custom-branding package to be updated that will fix this default
preseeded configuration before they can function again? If so, then
the CDD maintainers will have to maintain a number of these things and
will have to also find a way to deal with users changing the settings
on their machines and then having to reconcile with the package
maintainer, and/or with the CDD brander.
The thing we are toying with here is that there currently is:
upstream ---> package maintainer ---> user
but CDDs are turning this into:
upstream ---> package maintainer ---> CDD maintainer ---> user
micah
Reply to: