lots of dpkg ideas for discussion (was Re: GCC frepo (continue))
On Sat, 3 Aug 1996, Jimen Ching wrote in debian-user:
> And one more thing, I have a wish list. It would be nice if the install
> procedure does not waste it's time testing each an every package in a
> directory and displaying it. I.e. dpkg -iGROEB goes through the entire
> directory and displaying the selecton status. This is slow and painful.
> I don't see why the dpkg program can't scan the entire directory and
> create a list of all installed packages and display it in sorted order.
> Then it would go through the list of selected packages remaining which are
> marked 'not installed' and just install those (in sorted order, at this
> point, the section really doesn't matter does it?). There are 450+
> packages. I've only installed about 100 or so. I don't need dpkg to
> display the 300+ packages that I've marked as 'deselected'. Was this
> supposed to be a feature?
Yes, something like that would be great.
if dpkg were to keep a list of all selected files and a list of
pathnames to available deb files, then it could simply iterate through
the list of selected packages.
maybe a file called /var/lib/dpkg/selected. a simple file format could
be:
/full/path/to/file.deb package_name installed_version available_version
tab or white space delimited. The last two fields probably aren't needed
but could be useful...make them optional.
This would not only make dselect a lot faster, it would also implement
something which i asked Ian J about a few weeks ago...i need a way
to transfer the selections from one machine to another. So that, for
example, i could spend some time fine-tuning the installed packages list
and then just re-use that selection list on other machines. Useful for
administering a network of debian boxes or for 'mass-producing' them.
generating this list wouldn't be that hard...the hard bit would
be generating the list in the right order, so that depended-upon
packages are installed first. Maybe it would be better to replace the
installed_version and available_version fields with line number indexes
into /var/lib/dpkg/status & /var/lib/dpkg/available:
/full/path/to/file.deb package_name status_line_no avail_line_no
this file could also contain lines for uninstalled packages, just
commented out with a # symbol. Changing the selections would then be as
simple as commenting or uncommenting a line.
hey, the more i think about it, the more i think that this idea has a
lot of potential.
It may be just the sort of thing we need to separate the user interface
side of dselect from the functional...
...which would also give us an easy answer to those who don't like
dselect's interface: "here's the file format specs, here's a
c/perl/python/tcl/sh library for generating, parsing and manipulating the
file...go write your own user interface"
all that dpkg needs to do is know how to use this file (a new option of
"dpkg --auto=/var/lib/dpkg/selected", perhaps?) - dpkg does the hard work
of installing the packages, anything can be used to generate the file.
it would probably be a good idea to have a '--sanity-check' option as
well, to verify that the 'selected' file was OK to use.
as yet another alternative, if the status and available files could be
used to generate a gdbm database, dpkg would be a lot faster, and the
'selected' file here would only need to contain two fields...one is the
full path to the file, the other is the package_name which is used as an
index into the dbm files. (the selected file SHOULD be text so that it
can easily be edited with <insert_holy_text_editor_of_your_choice_here>**)
i think it's important to keep status & available exactly as they are -
there's too much stuff dependant on them being in their current format -
but to use them to generate a fast indexed database. old dpkg tools will
still work. new tools can be written to use the old style text files or
the new style database files.
another thought: maybe the path field should be a URL field. e.g.
"file://..." or "ftp://...."; or "http://...."; or "nfs://..." etc etc etc.
the "file://" could refer to localhost, or if given a remote host could
use rcp or rsh to fetch the file for installation...
it would be nice to be able to do something like:
dpkg -i ftp://ftp.debian.org/rex/binary-i386/base/base_1.1.0-14.deb
or
dselect --dist=unstable,contrib,non-free http://www.debian.org/dselect/i386/available.txt
or
dselect --dist=land-of-the-free ftp://ftp.civilised.country/debian/encryption/available.txt
I'm cc:ing this message to debian-devel for discussion.
Craig
** this means vi, of course. all others are unholy abominations :-)
Reply to: