Subject: GCC frepo (continue)

From: Jimen Ching <[email-masked]>
Date: Sat, 3 Aug 1996 20:32:46 -1000 (HST)

Oh, one more thing.  I wanted to check whether I'm still on the
debian-user list.  I sent a help message to the request robot, and got
back intro instructuions (subscribe/unsubscribe).  I wanted to know what
are the available commands to list the subscribed users.  How do I get
this info from the -request robot?  Most other mailing lists (using
listserv) has this info in the intro document.  Also, since I couldn't get
the help page, I don't really know if I'm subscribed.  I guess this
message will decide which.

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?

--jc
--
Jimen Ching (WH6BRR)      [email-masked]     [email-masked]

---

From: Craig Sanders <[email-masked]>
Date: Sun, 4 Aug 1996 19:26:34 +1000 (EST)

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

---

From: Craig Sanders <[email-masked]>
Date: Sun, 4 Aug 1996 19:26:34 +1000 (EST)

or

or

Craig

---

From: Ian Jackson <[email-masked]>
Date: Fri, 9 Aug 96 23:21 BST

Craig Sanders writes ("lots of dpkg ideas for discussion (was Re: GCC frepo (continue))"):
...
> the list of selected packages.

The information is already in dpkg's status areas.

If you take the first word from each Status: line in
/var/lib/dpkg/status and copy it to the corresponding place on another
machine you'll have copied the selectedness or otherwise of all the
packages.

Ian.

(Wild crossposting and CCs removed.)

---

From: Craig Sanders <[email-masked]>
Date: Sun, 11 Aug 1996 16:57:46 +1000 (EST)

On Fri, 9 Aug 1996, Ian Jackson wrote:

> > pathnames to available deb files, then it could simply iterate
> > through the list of selected packages.
>

Extracting the status line is easy.  finding where the files are located
isn't so easy.

maybe it's simpler to just leave the job of finding where the files are to
dselect...

it's still not clear what fields are actually needed by dpkg - if I do
something like: 

    grep -i "^$\|^Package:\|^Status:" /var/lib/dpkg/status | \
        sed -e 's/\(^Status:\)\([ 	]\)*\([^ ]*\)\(.*\)/\1 \3/'

or use an awk script like: 

    #! /usr/bin/awk -f

    /^Package:/ { print } 
    /^Status:/  { print $1 " " $2 } 
    /^$/    { print } 

both of which produce a list like:

        Package: vim
        Status: install

        Package: xterm-color
        Status: install

        Package: gnushogi
        Status: purge

        Package: xpaint
        Status: install

for obvious reasons, i'm a bit reluctant to experiment with the live
data in /var/lib/dpkg on my working system, so i have a few questions...

If i take this output and copy it to /var/lib/dpkg/status on a machine
which has just had base installed, then what will dselect do with it?
Will it get the remaining information (Version, Section etc) next time
[U]pdate is run?

How will dselect handle the fact that the "install" keyword is there
on the Status: line, but nothing else)? Is that acceptable/normal to
dselect?

As for the other ideas, it seems obvious that no one at all is even
vaguely interested in discussing ideas for improvements to or changes to
the way dpkg works.

> (Wild crossposting and CCs removed.)

(obnoxious comment left in)

Craig

---

From: Ian Jackson <[email-masked]>
Date: Mon, 12 Aug 96 02:58 BST

Craig Sanders writes ("Re: lots of dpkg ideas for discussion (was Re: GCC frepo (continue))"):
...
> Extracting the status line is easy.  finding where the files are located

You can get dselect to find the files for you.

> [ hacky stuff deleted ]

Just as well.

> Will it get the remaining information (Version, Section etc) next time

No.

> on the Status: line, but nothing else)? Is that acceptable/normal to

No.

You must do exactly what I said: copy only the first word of the
Status field of each package's entry, and replace the first word of
the corresponding entry on the other system.  The first word is the
`desired state' as set by dselect's selection interface and used by
the [I]nstall option.

If there isn't an entry for a package you want then make one like
this:
  Package: whatever
  Status: install ok not-installed

Ian.