[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dselect (or apt) wish list (fwd)



---------- Forwarded message ----------
Date: Wed, 11 Nov 1998 09:23:05 -0500 (EST)
From: Zack Brown <zbrown@lynx.neu.edu>
To: Michael Beattie <mickyb@es.co.nz>
Subject: Re: dselect (or apt) wish list

I'll try to respond to several people's responses in this one message, to
save space. Sorry for not quoting people explicitly. I wanted to reply to
everyone without peppering the list with a lot of little messages.

> 1) There doesn't seem to be any order regarding which packages are
> downloaded first. I suggest that, by default, dependencies should be
> downloaded before the files that depend upon them. Likewise, there doesn't
> seem to be any order in installation. I suggest the same thing for that.

Someone said 'apt' does. But 'apt' also deletes the package files once they
are installed (it doesn't even ask if that's what I want), which is another
wish I raised below.

Someone else didn't understand why such a thing would be desirable. I often
find, when downloading many packages, that the 'install' phase fails to
install packages whose dependencies have not yet been installed (even if
they've been downloaded), thus forcing me to go through the 'install' phase
again to clear up those failures after the dependencies have been installed.
Sometimes this takes three iterations of the 'install' phase.

The reason that downloading should also follow dependencies is so that if I
choose to interrupt the download (or if I have no choice about it) I can
still install what I've gotten without fear of breaking the system.

> 2) If there are a lot of .deb files sitting around, this slows down dselect
> by producing a lot of screen garbage during the "install" phase. I suggest
> that .deb files that have already been installed (or that have not been
> marked for installation) should not be displayed during this phase.

Someone suggested apt. Again, apt deletes installed package files
automatically, as soon as they're installed, giving me not even time to save
them with any certainty, unless I do strange things like ^K, which I would
hesitate to do on an installation program, which I want always to run
smoothly.

> 3) At the end of the "install" phase, dselect asks if it should delete
> installed packages. I suggest that either the default be changed to 'no', or
> else it be made possible to change the default via a config file. I really
> hate having a single keypress be able to wipe out days of downloading.

Most responses were that installed package files are not needed.

Not true! Even if I bought a cd, debian is under active enough development
that the cd will go out of date rapidly, and I don't want to download all
those packages each time. Nor do I want to move the packages to a different
location, because I want the install program to find them in the right
places when it needs them.

As far as the idea that I shouldn't be installing so often, all I can say
is, there are plenty of good reasons to re-install. Anyone who is trying to
understand (and configure) unix and linux and debian, who goes poking around
the filesystem as root, risks trashing things.

Also, as in my case, coming to debian from slackware, I had to do a lot of
poking around in order to learn the differences between the two systems. So
I've had to reinstall several times (in fact, I'm downloading slink right
now).

Bottom line: this is a very small and easy-to-grant wish, but for those who
want it, it's a big, hard-to-get-around problem. i.e. it prevents me from
using apt, since apt deletes installed packages automatically; and with
dselect, I have to be *extremely* careful I don't press the enter key at the
wrong time, when it asks to delete the packages.

> 4) It would be great to have a utility that searched my .dpkg/ tree and
> identified any debs for which newer versions have already been downloaded.
> That way I could delete the old ones and save space.

People said I should just delete packages that have been installed. I won't
answer that again, but I will point out that, given that one *wants* to keep
packages around, it's good to have a way to delete stale packages to save
space.

> 5) It would be great to do the following: take the output of "dpkg -l" and
> feed it to dselect, so dselect automatically selects all the packages given.
> That would make it much easier to install from scratch and still have the
> system the way I like it. In other words, once I initially have the system
> the way I like it, I could redirect "dpkg -l" to a file. Then, at any
> subsequent reinstall, I could tell dselect to select all the packages from
> that file.

Most answers gave `dpkg --get-selections` and `dpkg --set-selections`

All I can say is, thanks! That's the fastest granted wish I can remember. It
doesn't seem to be in the dpkg man page though, although I did find it in
'dpkg --help'

> 6) In the "install" phase, when dselect asks if I would like to select the
> individual packages, it would be fantastic if I could run up and down the
> list, choosing and unchoosing various items, while seeing a dynamic update
> of how much total space will be required. Also, even better would be the
> ability to specify which packages should be downloaded before others (to
> override the actions of suggestion #1 above).

Someone said this should be done in the 'select' phase. That seems right to
me too.

> 7) In the "select" phase, rather than interrupt a selection when a conflict
> or dependency is encountered, I suggest merely listing the dependencies and
> conflicts indented beneath the selection, while moving the cursor to the
> next item below that list. On the other hand, I have no problem having
> conflicts and dependencies pointed out to me when I try to exit the "select"
> phase (as the current version of dselect does).

Someone said that dselect had no idea how to resolve those conflicts. But I
still think that the same type of list we're currently confronted with when
a conflict or dependency occurs, should simply be inserted into the main
body of the 'select' phase. That way we can make the same choice that we
currently can make, but without interrupting the primary activity of
selecting packages.

We should not be forced to resolve all disputes immediately, because that is
distracting and time consuming. We should be able to proceed assembly-line
fashion, going through one phase entirely, and then moving on to another.
 
> 8) Last but not least, during the "select" phase, when searching for
> packages, only package names are searchable. I would really like to search
> descriptions as well.

Someone said we can always search /var/lib/dpkg/available. That's true. But
that's worse than not searching at all. The whole point of searching, is so
that I can quickly select and unselect packages. But if I have to be
switching between virtual terminals, it would go like this: search
/var/lib/dpkg/available for a package. Switch back to dselect or apt. Search
for the same package by name. select it. Go back to /var/lib/dpkg/available.
Search again. go back to dselect or apt. search for the same package by
name. Select it.

No, no, no. This would be much better: search for something. select it. hit
the "\" key. select the new package. Hit the "\" key again. select the new
package.

The whole point is to streamline the "select" phase as much as possible,
since it's so god-awfully time consuming.

Zack



Reply to: