Re: The Unified Package Manager

[Christoph Lameter <clameter@waterf.org>]

On Sat, 11 Jan 1997, Philippe Troin wrote:

phil >> - Immediate configuration of Packages. No delay for the configuration of
phil >>   daemons that might mean downtime (dselect).  No need for predependencies
phil >>   (dpkg).
phil >
phil >Then you'll have to find out the right order to install the packages, 
phil >and this will make circular dependencies prohibited.

No I dont have to do this. Unfullfilled dependencies will lead to the
retrieval/installation.  of the missing package

phil >> - Configuration Scripts are separate from the installation scripts and they
phil >>   can be repeatedly invoked without reinstalling the package.
phil >
phil >That's already the case for most of the important packages 
phil >(/usr/sbin/install-*).

I want to be able to move all interactive stuff out of the post/pre
inst/rm scripts. User interaction only in the configure script (which I
would like to see bound to the package and not just a script in the
/usr/sbin directory).

phil >> - Verification and accounting for modifications and the presence of each
phil >>   file on the system.  For each file a checksum is stored in the package
phil >>   managers database to allow for the detection of modifications and viruses. 
phil >>   The package manager can list all files not managed by the packaging system
phil >>   and can be used by the sysadmin to easily group and control
phil >>   non-distribution files on a system.
phil >
phil >You want to integrate tripwire functionality into UPM. Nice.

Its more than that. Tripwire cannot decide which file is not supposed to
be changed. Tripwire cannot show you which files were created and are
unaccounted for.

phil >> - Automatic retrieval and installation of packages a package depends on.
phil >
phil >Dftp handles this...

dftp is not the package manager but a separate program that does not have
the same intelligence as the package manager.

phil >> - Multiple Instances of UPM can use the Database simultaneously.
phil >>   (upm calls itself recursively to fulfill dependencies!)
phil >
phil >You'll have to be an expert locker to do it right...

Partially that is functionality coming with the Berkeley DB package.

phil >> - Packages with prefix ability can be installed in multiple locations.
phil >
phil >Unuseful ? Will complicate maintenance.

Useful if I want to test a newer release on a mission critical system.

phil >> - Multi-Architecture support in one UPM package. The package can list
phil >>   what binaries would fit what architecture and the upm manager will
phil >>   install the correct parts on installation. (Of course it can also
phil >>   be in separate packages if the size of those binaries is big).
phil >
phil >I don't want to ftp binaries for any architecture in every package...

That depends on the size of the binaries. If a package contains a 10K
binary for 5 architectures and the rest of the files (say 100K) is the
same for all architectures then I would prefer all binaries in one
package.

phil >General comments: Christoph, there's a lot a good things in there.I
phil >really dislike some of them. Some others have been discussed for a
phil >long time in the mailing lists (meta-packages), maybe we could start
phil >by implementing these.  How would you handle compatibility with the
phil >existing system ? 

Have a look at the upm package. After recent experiences I am ready to
give up on dpkg. I think there are basic conceptual issues here (like
predependencies, deferred postinst scripts) that cannot be addressed by a
review of dpkg.

--- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ ---
Please always CC me when replying to posts on mailing lists.


--
Please respect the confidentiality of material on the debian-private list.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com