El Sun, Oct 03, 2004 at 12:58:48PM +0200, Jose Carlos Garcia Sogo va escriure: > El dom, 03-10-2004 a las 02:10 +0200, Sergio Talens-Oliag escribió: > > El Sat, Oct 02, 2004 at 08:32:12PM +0200, Miguel A. Arévalo va escriure: > > [...] > > > > I've been already thinking about that and found that the solution is > > > already developed, we can use the alternatives system already present in > > > Debian, so: > > > > I think that your idea of using the alternatives system is not bad and maybe > > can be used for the branding of some applications, but, to be fair, it seems > > an overkill for something that only implies a variable value change inside a > > configuration file. > > There are basically one problem with configuration files: > - A package cannot touch any configuration file of other > package, at least if the fomer wants to be in Debian pool. > Also, you will need to do that in postinst, as dpkg doesn't > allow to overwrite a file. And you cannot overwrite user(admin) > configurations without asking first Yes, but I'm not saying we should go against Policy nor change configuration files when installing CDD packages, what I'm saying is that packages should implement a way to change configuration files using debconf, allowing CDDs to provide a way to customize configurations, either using pre-seeding at installation time or telling the administrator to apply the CDD settings using a script called by himself. > > Anyway, maybe I'm wrong, but it seems that every body is trying to avoid > > handling configuration files and usually they are the best place to do this > > kind of things... i.e. what happens if the branding has nothing to do with > > files (like variables that indicate colors or names or whatever)? > > Then you have two options: > - Make maintainer use debconf, and preseed debconf datatabase. This has > the problem that right now there isn't any way to ensure that the > preseeding will be done (unless at d-i installation time), as dpkg > doesn't assure you that packages will be configure in order. No, the pre-seed is only done automatically if installing, I don't think applying it when installing a package is a good thing, if somebody installs a new branding package on a running system is better to tell him to apply it by hand (I mean calling a script that does the preseed and calls the reconfigure scripts). The problem if we apply pre-seeding at dpkg installation time is that we can also be violating Policy (or at least the Policy spirit), because we can override values changed by the administrator on the debconf database by hand. > - (Evil hack) Make the maintainer use alternatives also for the config > file. No, alternatives is a bad option and has to be avoided, if the configuration file changes it is quite easy to make the program fail, but if the maintainer of the package handles the debconf answers he or she can fix new options gracefully. By the way, one thing we have to find is a way to let people now that a package's debconf questions have changed between releases, to let CDDs relaying on pre-seeding for customization review how changes can affect them and fix it if needed. > Of course, any of these should need a wider agreement, so maintainers > feels that this must to be done. Sure, but my point is that what don't need to change anything, only try to convince maintainers that having customizable packages that use debconf is a Good Thing and provide a something like a dh_debconf helper script for the common cases (usually overwriting variable values). For more complicated customizations maybe *debconf* is not the right solution, but those are probably exceptions that will always need a different customization mecanism. -- 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