Re: My take on the whole approach (was: Re: Old stuff)
Aaron Van Couwenberghe wrote:
> On Tue, Dec 22, 1998 at 01:48:06PM +1000, Anthony Towns wrote:
> I don't agree with lots of this. for the specific reasons:
>
> We shouldn't really need to force package maintainers to use our
> scripting language to be able to use these facilities.
> We should really use a powerful internal language like perl for the
> internal handling code, and provide a flexible interface.
> We really should put in place a system that won't disrupt life for
> anybody, if anything at all is going to be put into place.
>
> Conceptually, all of these issues are fairly easy to address when
> they are taken out of context from one another; given the best solution to
> each, a course of action can be planned that will bring the best results.
>
> for issue #1, (maints being able to do things like they did before), we
> could simply tell maintainers that their configuration scripts *must* take
> the --nointeractive option and be able to take all of their variables on the
> commandline, in the order that they are declared in their debian/vars file
> (explained later)
> for issue 2, DBI is ideal because if anyone *wanted* to set up a
> three-tier system where a database engine is not used but the options file
> is mastered and transferred to each host, a simple perl module can be
> written to drop-in (polymorphism is neat) and be *completely* transparent
> even to debian-admintool (ie the internal code).
> for issue 3, the answer is to make everything following the current
> standards-version to not break because of debian-admintool's existence.
> Hopefully it can be implied that statement is retroactive as well but that
> would be more difficult.
>
> The way to handle this is to *change nothing* in the standards
> version but two things:
>
> 1) each package following standards version XXX must have a file included
> named debian/vars. the contents might look something like this, for a berlin
> display server:
>
> ENCRYPTION yes (or 1 -- yes/no might become boolean synonyms)
> ORB_ENC_TYPE kerberos
> GROUP berlin
> MIGRATE_WIDGETS yes (or 1)
>
> 2) each package following standards version XXX must be able to take the
> 'nointeractive' option, and a list of variables (guaranteed to be in the
> order they are from debian/vars), for a postinst format such as this:
> postinst --nointeractive ENCRYPTION=yes ORB_ENC_TYPE=kerberos GROUP=berlin
> MIGRATE_WIDGETS=yes .... ad infinitum.
>
> To simplify this, small modules (and/or libs) could be guaranteed to be
> present that perform functions like, in C, splitting the entire list into a
> flat array of type 'char *', omitting the keys. In perl, one call could
> separate the commandline into an associative array. Similar behaviors in
> bash.
>
> one more thing to address. How do we force postinsts to communicate their
> configuration info to debian-admintool? we could require the package print a
> list of the same form as debian/vars, for every variable that is not
> included in debian/vars or for which the default has been overridden.
>
> [snipped for brevity, although probably too late]
Could you discuss your ideas as they relate to configuration data
where the variables themselves must be determined programatically?
For example, in a mail package, you could set up:
POPSERVER=mail.myhost.com
But there might be more than one mailserver. There may be ten.
You cannot reasonably expect the maintainer to know the needed
variables when packaging.
What if you need a configuration option set for each ethernet interface
on the installed machine.
CONFIG_FOR_ETH0=xxx
CONFIG_FOR_ETH1=yyy
CONFIG_FOR_ETH2=zzz
Most users wont need info for 3 ethernet configurations, but many will.
I wont belabor examples. You understand the point I'm trying to make.
I'd be interested in hearing your take on this.
-Mitch
Reply to: