Re: 'install' and package management

[Mario Salzer]

Paul Eggert <address@hidden> wrote:

> Something like that might be nice, as an option.  It ought to be
> designed with modern package facilities in mind, e.g. the aptitude
> package of Debian GNU/Linux
> <http://packages.debian.org/stable/admin/aptitude>.  The trick is to
> have a useful command, that a fancier packaging facility like aptitude
> could make use of.  I'm afraid it's not a trivial task.  Is this
> something you could look into?

The aptitude database isn't the right target here, as it is a binary
thing. However the dpkg database is a really Unixish file store.

But whatever, I'd say that if 'install' did track installed files, it
should ultimatively maintain its own database for two important reasons:

- be independent from any GNU/Linux distro
- have as little overhead as possible when copying files

So instead of directly targetting /var/lib/dpkg/status (or /available)
it would simply append a text entry to say /var/local/install.log
(assuming this gets important it may be useful to have it there). The
format could be something like:

   Package: openssl
   Version: 0.9.9.9j-9
   Date: Wed Feb 31 23:59:97 GMT 2007
   Command: install -g staff -s -D -v /root/openssl-0.9/src/lib/... /usr/l...
   Files:
     /usr/local/lib/libssl.so.0.9.9.9_9-9
     /usr/local/include/...
   \n
   \n

It did so for every single file it copied, which then of course leads
to an too long 'install.log' file, which must be rearranged by some
helper tool.

And another helper tool then later had little problems converting
this into the format useful for dpkg or so. It simply had to take
all entries from that hypothetical install.log and rename the package
names into "local.openssl" for example so they didn't clash with
real/existing entries of the dpkg database.

It is trivial to seduce the Version: number and an appropriate Package:
name from installs SOURCE parameter, but only using a regular expression
like
  SOURCE =~ /...\/(.+)-(\d+\.\d.*)\/.../

That is that whole idea was better implemented in a Perl script me
thinks. OTH 'install' is ought to be a more always-present system
tool so this effectively goes against its purpose (Perl isn't
neccessarily always present, not to mention working, except for Debian
maybe).
However the idea looks useful enough to me to just try it that way
(either a frontend to the real /usr/bin/install or a replacement).

mario