El Tue, Mar 09, 2004 at 09:34:01PM +0100, Conrad Newton escribi� From Andreas Tille on Tuesday, 2004-03-09 at 14:19:43 +0100: > > On Tue, 9 Mar 2004, Sergio Talens-Oliag wrote: > > > > > What I don't know is how good is cfengine for upgrades, mainly because > > > I've never used it ... ;( > > If you ask me I'd prefer a tested tool like cfengine over the manual > > approach you described above. > > I am not questioning the usefulness of cfengine---and yes, it is used > by skolelinux to configure the system. My question is, is this the > rational thing to do? Don't packages and configuration go together? Yes, each package needs/has its own configuration, but there is only one default configuration and if the user needs to provide information for this configuration you can use debconf. > The problem with building custom configurations into packages is of > course that in the end, you may have 200 different configurations, > or 20,000. When you include different configuration possibilities > in the packages, where do you draw the line? The package must not include the configurations, only the mechanism to generate them. > Still, I believe that packages and configuration are logically > connected. Imagine a future where we have many different CDDs. > Maybe I want to have a blend of two or more different CDDs. > If cfengine is my tool, I now have to tear apart the cfengine > configuration file for two different CDDs and glue them back > together again. Does this make sense? I do not think so. > I want more flexibility! Well, I imagine that you can have one cfengine script and one list of debconf answers for each package. A different thing is the way you package those files to distribute them with each CDD, probably the more logical aproach would be to generate one package for each task. If two CDD give different configurations for the same package we can define some kind of automatic confict resolution mechanism to know which files we want to use or ask the user what he wants to do. > I suppose what I want (without really knowing if this already > exists) is "configuration packages" that are intimately connected > with "binary packages". The "configuration packages" might well > be in places other than the standard Debian archives, because > the burden of supporting many many different configurations is > probably too much for Debian too handle. Well, if we agree on a standard mechanism to define *external* configuration scripts and on a format to package those scripts and the debconf answers for each package, storing them in a Database and making them available via web is trivial, and I don't think there will be so many for each one. > But what I gain is flexibility---I can offer my configuration > files on relatively weak server, because downloading a few > textfiles requires so little bandwidth. The binaries can > be downloaded directly from Debian. If a particular set > of "configuration packages" proves to be enormously popular, > it could be included in standard Debian. Well, what I don't really understan from your message is if you want a way to preconfigure packages or a way to replicate your *own* configuration. The interesting aproach for me is the first one, because it can be used by CDDs and is more or less *upgradable*, for the second use probaly a tar file for each package is enougth. -- 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