Re: Rethinking UPMs package format

["Richard G. Roberto" <richr@Bear.COM>]

On Thu, 16 Jan 1997, Christoph Lameter wrote:

> I would be willing to do the following:
> 
> 1. Go through all patches for dpkg and through all the bug reports and do
> whatever can be done to fix things. Make it use debmake. All that is no
> major change and no major effort. And then release a new dpkg.
> 
> 2. Build on that base a new package called d3pkg which will merge some of
> the upm ideas into dpkg hopefully resulting in a Debian format 3.0
> binaries some day.
> 
> (The ascii file idea has been dropped since I already have made it
> available through debmake for regular .deb packages <G>).
> 
> Concrete Ideas which I think can be done soon:
> 
> - Make packages immediately run the postinst after unpacking

I don't uderstand the difference here.  Dselect is where this
issue hurts -- that's where is needs to be addressed.  The only
time packages shouldn't be completely installed (hopefully async)
is when there is a circular dependency.  These relations are
_not_ the norm and should be treated as exceptions.  There is no
reason to impose the restrictions associated with these relations
an all package relations.  But, as I said, I think this should be
addressed in dselect.  Adding an option to dpkg to have more
granular control over package installation is fine, but it
doesn't address the problem in dselect.

> 
> - Allow a separate "configuration" script in addition to the regular
>   scripts which should do all interaction with the user and which will
>   be executed at configuration time.

This is an excellent idea.  In the absence of a better mechanism,
we really need the ability to to non-interactive installs.

> 
> - Automatic retrieval/installation of packages depended on and not
>   installed.

See below.

> 
> - Try to integrate Berkeley DB style databases into dpkg for fast file
>   lookups and allow multiple types of configfiles + checksums for all
>   files.

Please do!  I understand people's concern about storing data in
non-ascii format, but please consider this.  The structure of the
data alone would speed things up considerably.

It seems that this is turning into a "send your dpkg wishes to
Christoph" but here goes anyway:

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

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

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

I think there are many more gains to be had by putting dpkg's
core functionality into a library interface, such as simpler
extensability, etc.  The database format for storing metainfo is
also another big gain winner.  It not only speeds things up, but
(if the data is structured well) it also provides us with another
tool that could be leveraged for better package management in the
future.  The argument that "it needs to coded really well for it
to work, so we shouldn't do it" is bogus.  Having a database for
metainfo storage would allow us to easily store state information
about a package and it would be trivial to implement a "roll
back" feature or "recovery" feature, in the even of disaster,
based on this state info.

A package configuration database could give the same leverage to
all of our config data, but that's another issue :-)

[1] "Finished" should never mean "carved in stone".  In this
sense, I think it means "not lacking anything at the moment".

Richard G. Roberto
richr@bear.com
011-81-3-3437-7967 - Tokyo, Japan


--
*******************************************************************************
Bear Stearns is not responsible for any recommendation, solicitation, offer or
agreement or any information about any transaction, customer account or account
activity contained in this communication.
*******************************************************************************


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