FWIW

-- 
Want to get a clue on IPv6 but don't know where to start? Try this:
* Basics -> http://www.onlamp.com/pub/a/onlamp/2001/05/24/ipv6_tutorial.html
* Setup  -> http://www.onlamp.com/pub/a/onlamp/2001/06/01/ipv6_tutorial.html 
Of course with your #1 IPv6 ready operating system -> http://www.NetBSD.org/

---------- Forwarded message ----------
Date: Fri, 21 Dec 2001 18:00:00 -0500
From: "Eric Gillespie, Jr." <epg@pretzelnet.org>
To: op-tech@openpackages.org
Subject: Some ideas for the new package manager

I was going to commit this to the design doc, but i figured i'd
fly it by the list first.

Ideas about conf file handling
******************************

/etc/opkg/actions/ contains the symlinks which are used to perform
installation and deinstallation actions.  Here are the defaults:

install                         -> /usr/bin/install
deinstall                       -> PREFIX/libexec/opkg/deinstall
deinstall-conffile              -> PREFIX/libexec/opkg/deinstall-conffile
install-conffile                -> PREFIX/libexec/opkg/install-conffile
upgrade-conffile                -> PREFIX/libexec/opkg/upgrade-conffile

The install action is called with the traditional BSD install
arguments.  An example replacement action is a program which checks
for setuid bits and doesn't set them on the installed files.  The
default action simply installs the file w/out special treatment.

The other actions are called as follows:

deinstall TARGETFILE
deinstall-conffile TARGETFILE PKGNAME PKGVERSION
install-conffile FILE TARGETFILE PKGNAME PKGVERSION
upgrade-conffile FILE TARGETFILE PKGNAME OLD_PKGVERSION NEW_PKGVERSION

The default deinstall action simply removes the file or directory.

The default deinstall-conffile action simply removes the file as well
as OPKG/TARGETFILE.PKGNAME_*.

The default install-conffile action installs FILE as TARGETFILE as
OPKG/TARGETFILE.PKGNAME_PKGVERSION.  If there is no OPKG directory in
TARGETFILE's target directory, it will be created.  If there is no
file called TARGETFILE, FILE will also be installed there; otherwise
it is left alone.

The default upgrade-conffile action first determines if TARGETFILE is
identical to OPKG/TARGETFILE.PKGNAME.OLD_PKGVERSION.  First it checks
the timestamps; if they are identical it assumes the user has not
edited TARGETFILE.  If the timestamps are not the same it runs cmp(1)
to determine if TARGETFILE.  Finally, it gets to work: If the user has
not edited the file, it installs FILE as TARGETFILE; if the user has
edited the file, it does not.  Either way, it also installs
OPKG/TARGETFILE.PKGNAME_NEW_PKGVERSION and deletes
OPKG/TARGETFILE.PKGNAME_* except for
OPKG/TARGETFILE.PKGNAME_OLD_PKGVERSION.  In this way, the user will
always have her own copy of the conffile, the current default
conffile, and the default of the previous version if there were one.
This makes it easy for the user to incorporate new settings into her
own customized copy.

OPKG directories are automatically pruned by deinstall-conffile if
empty.

The command line of each action is logged to the opkg logfile.
There should be a facility for the action to add additional
messages to the log (maybe inheriting an open file descriptor?).

When removing a package, libopkg can be told not to touch the
conffiles; then it will not run /etc/opkg/actions/deinstall-conffile.
In this case, the package is removed from the installed packages db
but its CONTENTS file is left in place.  This is to facilitate the
user later deciding to go ahead and remove the conffiles as well.

*******************************************************************************

Also, Doug Porter and i were arguing about Debian's practice of
splitting packages into so many binary packages.  Part of this is
to save mirror space by putting all arch-independent files into
separate Arch: all binary packages.  We already plan to implement
sub-packages, so for example there would still be only one
'mozilla' binary package, but it would contain sub-packages such
as 'lib', 'doc', etc. and the user does not have to install them
all.  That still doesn't solve a few problems.

One is the idea of multiple versions of shared libraries being
installed at once.  Debian breaks packages providing libraries
into multiple binary packages with the soname appended to the
package name (e.g. libgnome32).  A better solution would be to
allow some sub-packages to remain on the system after the rest of
the package is removed or upgraded.

The issue of saving mirror space can be accomplished this way:
currently, a package comes in two files; we can instead say that
a package comes in two files: foo-1.0-${arch}.zip and
foo-1.0-all.zip.  The arch file can be omitted if the package is
completely architecture-independent; the -all file will always be
present, if only to hold meta-data.  Files would go into one or
the other file regardless of which sub-package they belong to.

-- 
Eric Gillespie, Jr. <*> epg@pretzelnet.org

"When everyone has to reinvent the wheel, many people invent
 square wheels."

_______________________________________________
op-tech@openpackages.org
http://openpackages.org/mailman/listinfo/op-tech