Packaging and installation

Mathew Edward Kovach mkovach at
Tue Oct 24 10:07:20 PDT 2000

On Tue, Oct 24, 2000 at 11:12:06AM -0500, Jeffrey Watts wrote:
: Seems to me we've had a consensus for a long time.  It's always been RPM.  
: The only reason that the issue ever comes up is that someone new to the
: mailing lists jumps in and starts dragging the issue up again.

If I may, the problem may be a bit more in defining things a bit better.

The way that I see it (and I have looked through the archives, and attempted
to "get up to speed" is that the objectives are not that clear.

In defining a package type it seems to be you are actually doing serveral

o pre-install checks.
  Check dependancy, etc.

o software install.
  Put files where they need to be.

o post install configuration.
  Update config files
  Run cleans up
  Update system letting it know that you just did.

(Yes, I'm living quite a bit out, but hopefully my idea is there)

What I see, to accomplish the first part of dependancy, the effort to define
a package is a bit of overkill, when really it is a way to define what 
is installed on the system (Which in part effects that last part).

Would it possible to say that the package database is the rpmdb?  This would
mean that any installation package system would standardize on the rpmdb
but would be free to complete the non-db related package managment as 
it see fit?  I'll admit, I have personally looked into it, but I don't
see any major problems if say, and .tgz or .deb package used the rpmdb 
format (as well as it own).  Yes, but be a bit of overkill, but
it would accomplish the goal, wouldn't it?  You would have a central
area for installed software information, and could very easily standardize
on the format the data is stored.  

I hadn't seen this take in the previous discussion.  It is possible
that I missed it though.

: Note that Nicholas Petreley, when he started the current thread,
: acknowledged that we have agreed on RPM -- he just was wondering if there
: might be a better way, something that no package manager has done before.  
: Others pointed out that changing our package standard isn't really
: productive at this point.  Note that none of this implies that we haven't
: decided on something.

Here is my problem, I don't think package management is what we want, as
much as package INFORMATION.  Am I thinking wrong on this?  
: Put it this way: RPM's the starting quarterback here.  The LSB isn't going
: to consider some new proposal unless it's completely fleshed out and
: addresses ALL of the issues involved (which are considerable).  Note that
: packaging systems like RPM and DEB didn't get coded overnight.

I agree here, the better way might be out there, and it is not available.
My problem is that standard might be trying to define too much?  All package
management systems have good and bad points, but they have one BASIC purpose,
to store information about the files on the system and get get the files
installed.  Anything else, as I see it, is extentions of that.

: Also, we've all pretty much decided that it's not worth our time to pursue
: an alternative solution, as RPM does 99% of what we want it to.  So that
: pretty much means that if anyone wants to see this done, they have to do
: it themselves.
: Remember, the LSB isn't here to pursue technical perfection.  It's a
: _practical_ standard.  RPM is the path of least resistance.  Folks can
: argue its technical merits until they're blue in the face, but the fact is
: that RPM has the largest installed base, it does what we want it to do,
: and there are tools that allow us to use RPM on non-RPM based systems.  
: This is a fait accompli.

I agree, it is there lets use it.  Or at least parts of it.  Manipulating
the rpmdb shouldn't be that hard, so making LSB "ready" package management
system that modifies a standard database could achieve the goal of 
standard package management without limiting the software used to do it.

Mat <mkovach at>
Blinky Light Sync-er.

More information about the lsb-discuss mailing list