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

Re: custom branding and CDDs



On Sun, 3 Oct 2004, Sergio Talens-Oliag wrote:

 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.
Definitely.

 Yes, but then you can't have two different brandings installed, and I see no
 reason not to be able to do it.
Having more than one brandings might not be a very frequent issue
in real live, but IMHO if we can implement this sanely I would prefer
this solution.

 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?
I guess we need a mechanism to file stronger than wishlist bug reports
to accompolish this.

 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.
Well, if we could increase the interest in CDD "political" I would see a
way:
   Several people noticed that the huge package base has drawn us into
   a new quality of a distribution and that this quantity of packages
   needs a more sane handling.  Until now there was no proper solution
   that I would know of to resolve the release cycle problem which is more
   or less caused by the new quality we reached.

   So people might be sensible enough to consider a policy change which
   might go into this direction (very draft thought for the moment):

     To increase the flexibility of Debian and increase the acceptance
     of Debian in enterprises and for Desktop use, very different
     configuration options are needed for a certain amount of packages.
     If there is a patch which increases the flexibilty of a package
     by not breaking anything at normal Debian systems the severity of
     this bug might be increased if there is a CDD (or derived distribution)
     which needs this change to prevent a fork.

This is very draft wording, but I hope you get the idea.  I guess if we
could turn this idea into a sane wording we might probably be able to
have a post-sarge change and get some power which should allow even NMUs
for certain packages or to call the technical commitee to get things
implemented we really need.

 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.
This could be done if the above would be acceptable.

 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/.
Exactly this would I definitely prefer.

IM> Thoughts? How are other CDDs dealing with this?
I'm really happy that Ian started with this thread in debian-custom!

Kind regards

         Andreas.



Reply to: