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
