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

["George Pajari" <George Pajari Faximum com>]

Thank you for proving my point.

The fact that the RPM architecture does not adequately handle configuration
means that everyone has come up with their own, incompatible, non-standard
way to address this failure (of which running shell scripts manually after
the installation is merely the most general solution).

As a software developer, having as many solutions to the RPM-can't-configure
problem as there are distributions is pretty well useless. We're certainly
not going to spend the time to build n versions of our product. Coping with
the gratuitous differences between "standard" Linux distributions (or
between different releases of the same distribution) is grief enough.

I have no problem with separate tools for separate functions. The difficulty
is that the RPM people did half the job. By not providing the configuration
functionality within RPM and not providing a separate configuration tool to
work with RPM they left the job to each distro to solve in their own
incompatible way as you have illustrated in your post.

I would argue that whether configuration is a part of the rpm tool or a
separate beast is an implementation detail. The architecture ought to have
encompassed both aspects of the problem. By ignoring the configuration part
of the problem we not only have separate tools (perhaps a good thing) but
separate architectures (a bad thing).

Now if one of the approaches you outline becomes widespread (and part of the
LSB) then the argument of whether or not configuration ought to be part of
RPM or a separate tool will be moot. Until then, the fact that RPM doesn't
do it, and no other tool does it in a consistent manner across distributions
is a significant weakness.

Whether one considers this a weakness of the RPM architecture specifically
(which I do) or a failure of Linux/Gnu generally is more a matter of
semantics. It's broke and needs to be fixed. And fixed in the same manner
across all major distros.

Which is why, although it may be better implemented as a separate tool,
incorporating it under the RPM umbrella (at least from a naming and
architectural point of view) would be extremely helpful in getting it
accepted across multiple distros. For political reasons if no other.

----- Original Message -----
From: "Brandon S. Allbery KF8NH" <allbery@kf8nh.apk.net>
To: <rpm-list@redhat.com>
Sent: Tuesday, October 30, 2001 8:45 PM
Subject: Re: RPM Limitations (was: while i'm at it)


> On Tuesday, October 30, 2001 20:36:52 -0800, George Pajari
> <George.Pajari@Faximum.com> wrote:
> +-----
> | While we have little choice but to live within the restrictions of the
> | existing RPM approach (at least for the foreseeable future), it is
pretty
> | obvious that not paying any attention to the need to configure software
> | is a major shortcoming of the RPM architecture.
> +--->8
>
> Ummm, what?  RPM isn't in that business.  Anaconda (Red Hat) and YaST
> (SuSE) (and Mandrake has something as well IIRC) are layers on top of RPM
> which add configuration, etc; it seems to work pretty well for most
people.
>
> | While this limitation can be brushed aside with trite sayings such as
"rpm
> | is an installation tool, not a configuration tool", it ignores the fact
> +--->8
>
> No, it *acknowledges* the fact that it's for an operating system designed
> around the concept of separate tools for separate functions, as opposed to
> unstable, teetering monoliths that get in each others' way like on certain
> other OSes.