Re: Rethinking UPMs package format

[Christoph Lameter <clameter@waterf.org>]

On Fri, 17 Jan 1997, Richard G. Roberto wrote:

richr >> - Make packages immediately run the postinst after unpacking
richr >
richr >I don't uderstand the difference here.  Dselect is where this
richr >issue hurts -- that's where is needs to be addressed.  The only
richr >time packages shouldn't be completely installed (hopefully async)
richr >is when there is a circular dependency.  These relations are

Not running postinst means daemon downtime meaning outages....

And IMHO there are no real circular dependencies BTW.

richr >_not_ the norm and should be treated as exceptions.  There is no
richr >reason to impose the restrictions associated with these relations
richr >an all package relations.  But, as I said, I think this should be
richr >addressed in dselect.  Adding an option to dpkg to have more
richr >granular control over package installation is fine, but it
richr >doesn't address the problem in dselect.

I think others can deal with the dselect problem. Dselect needs to be
separated from dpkg IMHO. What I want is a package
manager that I can use in a reliable way to upgrade our mission critical
servers. That change in dpkg would allow us to use the current dselect to
upgrade those.

richr >It seems that this is turning into a "send your dpkg wishes to
richr >Christoph" but here goes anyway:
richr >
richr >I would very much like to see dpkg split into a library and a
richr >tool that uses it.  All dpkg functions should be made into
richr >calls into the dpkg library.  Then dpkg could easily be modified
richr >as a tool in such a case to make calls to another library for
richr >another package format (i.e. an rpm library).  This would give us
richr >more flexibility and easier management of the dpkg package.  I
richr >believe that dpkg should be continually developed.  Although
richr >laregely the policy and package format is "finished[1]", the
richr >tools we use to implement this should never be.  If we have such
richr >a library, dselect could be modified to make calls to the same
richr >library instead of system()'ing dpkg iterations.

That is certainly a good idea to further modularize dpkg. The library
interface is dependant on a stable interface though. I would like to do
the library later when things work the right way. Right now dpkg,dselect
is a big mess and it needs to be separated into multiple packages which
will be difficult.

richr >Automatic retrieval of packages based on dependency info is
richr >probably not possible with virtual package dependencies. But even
richr >if an actual package _list_ could be obtained "on the fly" and
richr >retrived, having this functionality available through a library
richr >interface would allow it to be used in dpkg and dselect alike.

Automatic retrieval would enable the meta-packages we want to have.
Simply set up a package with the dependencies on all packages in that
metapackage and they will be installed by automatic retrieval.

richr >The mechanism by which dpkg implements a non-interactive
richr >installation of a pacakge should also be coded so that it could be
richr >changed easily.  Having an accompannying script is fine for
richr >getting this functionality quickly, but in the long run, a
richr >central repository where configuration info could be stored and
richr >managed would be better.

It is probably not a big issue to simply add a database to dpkg when we
are at it for other things.

The problem is though how to get the users configure the important values
in this database. And debugging the final construction with the multiple
dependencies between packages might be a nightmare.

--- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ ---
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