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

Re: RPM Limitations (was: while i'm at it)



On Wed, Oct 31, 2001 at 09:06:20AM -0500, Ian Peters wrote:
> 
> I'm not an expert, but here's the basic architecture.

I'm even less of an expert than you, BUT ...

> 
> Packages ship with debconf scripts written in a psuedo-language that
> ties together perl/shell script snippets with high-level constructs like
> radio buttons, toggles, text entries, etc.  All configuration options
> must have reasonable defaults specified.

... can you enumerate the "debconf scripts"? If so, I'll look at adding
rpm tags to carry the glop around in a header. The next item on the
agenda would be to figger where/when the glop might be used

> 
> A variety of front-ends are supplied, which can be selected from using
> global configuration, overridden with environment variables.  Frontends
> include noninteractive, text (basic), dialog/slang, gnome, etc.  A
> fallback order can be specified when a given frontend is insufficient.
> 

Details that can be (actually are) handled in rpm AFAICT.

> The package manager is taught to look for these debconf scripts, and can
> run them all at the beginning of a transaction, or during the course of
> the transaction.  Additionally, the configuration can be reinvoked at
> any time through the dpkg-reconfigure command.
> 

Nope, no way is rpm gonna run these scripts at the beginning or during
a transaction as currently constituted. However, that doesn't prevent
an installer like red-carpet from doing anything it wishes before,
between, or after, calls to rpmRunTransactions().

> So, we've got a complete configuration mechanism, integrated with but
> not tied to the package manager, which can be turned on or off at the
> users discretion, which provides a standard interface through which to
> request user input, and allows the execution of arbitrarily complex
> scripts to make use of this input.
> 

Again, rpm will never request user input in it's current modes of operation.
There's still a *lot* of wiggle room here :-)

> Those who know me well know that I'm a frequent critic of debian package
> management design decisions and implementation -- yes, even more than I
> am with rpm :-) -- but in this case, I think they've done something
> pretty slick.  I'm not necessarily suggesting the wholesale adoption of
> debconf, but as a starting point for a configuration mechanism, debconf
> seems to make a lot of sense.

Yeah, but is debconf useful?

73 de Jeff

-- 
Jeff Johnson	ARS N3NPQ
jbj@jbj.org	(jbj@redhat.com)
Chapel Hill, NC





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