Re: Uninstall

[Steven W Orr <steveo at world dot std dot com>]

-- 
----------Time flies like the wind. Fruit flies like a banana.----------------
--------Stranger things have happened but none stranger than this.-------------
Steven W. Orr      steveo@world.std.com     <site of former bang addr:-)>
---------------"Listen to me! We are all individuals."-------------------------

On Thu, 12 Nov 1998, Per Bothner wrote:

=>I think you are mixing two (or three) different things:
=>
=>(1) The installed package data base;
=>(2) A file format used to distribute and install packages (usually
=>pre-compiled binaries), such as .rpm (for RedHat) and .deb (Debian);

Please do not discount the fact that rpm distributions come in both src
and binary. The src gets installed and then the binary rpm is constructed
from the src. The binary is then installed.

=>(3) A program that manages (1) and (2) (rpm for RedHat and dpkg for Debian).
=>
=>While for a *user* (and application distributors) it is most useful
=>to standardize on (1), from our point of view, it may be more
=>critical to standardize on (1).

I don't understand this.

=>It seems to me that installing a binary package should have
=>the same effect as 'configure && make && make install'.
=>If you want to be able to install a package installed from source,
=>it seems to me it should be using the same package database
=>as rpm or deb packages use.

So far so good.

=>However, note that packages installed using a package manager
=>normally install into /usr.  However, a GNU source package by
=>default install into /usr/local, but may be installed elsewhere
=>(such as /usr) depending on the --prefix configuration setting.
=>That says that the locacation of the package database should be
=>somewhere underneath $prefix (or $exec_prefix).

Note that a binary rpm is exactly that, binary. It is therefore also
preconfigured. A foo-9.9-1.i386.rpm does want to typically install in /usr
though it could go anywhere that the package author designs it to. A
foo-9.9-1.src.rpm could configure itself to go in different places
depending on what platform it is built on.

=>Conclusion:
=>* There should be a standard package database format.
=>The format can be extensible, but it must support at least
=>"unstall PACKAGE_NAME".  It should also support querying to
=>see which files belong to which package and vice versa.
=>* The location of the package database depends on the $exec_prefix
=>used to configure each package. In other words, there is a
=>separate package database for each $exec_prefix.
=>For discussion, assume this is $exce_prefix/lib/packages.
=>* 'make install' should should update the package database in
=>$exec_prefix/lib/packages/PACKAGE_NAME, such that a later call
=>to "unstall PACKAGE_NAME" will cleanly remove it.
=>* Binary package managers (such as RedHat's rpm, Debian's dpkg)
=>should use the same package database, which for normal system
=>installs would be /usr/lib/packages.

Correct. In addition, rpm provides other services like package signatures
to make sure that what you have is correct and complete. It also provides
for an ability to fix a corrupted database.

=>
=>Now we just need a volunteer to study the RedHat and Debian
=>package database formats (at least), come up with a design that
=>fits both systems' needs, and then sell it to RedHat, Debian,
=>Slackware, SuSe, ... and the appropriate Linux standards-setting
=>groups ...  (The critical people to get on board are Debian, as
=>most affiliated with GNU, and RedHat, as the most visible Linux
=>distributor.  Plus of course the FSF (i.e Stallman), since we are
=>talking about extending a new GNU standard.)
=>
=>> Is it maybe appropriate to propose that RPM be more widely used than just
=>> for RedHat distributions?

I agree. I think this conversion from .tar.gz files to a proper enhanced
package manager is way overdue. I have experience with both the HP package
manager and rpm, though rpm is the only one that is PD.