Re: Bug#1385: dselect selects some packages without asking
Ian Jackson <iwj10@cus.cam.ac.uk>
> Bill Mitchell writes ("Bug#1385: dselect selects some packages without asking"):
> > I've been using the various incarnations for some time, and I still
> > quite often have dselect install packages which I hadn't expected
> > to be installed.
>
> The reason for this usually appears to be that you wanted to leave out
> some packages that are required to satisfy Recommends or Depends
> fields in others you are installing. Only experienced users, who know
> how to override dselect and make it stick, should do this.
Said another way, dselect makes it so difficult not to have e.g., emacs
installed, that only experts should try to avoid installing e.g., emacs.
> > Perhaps the [I]nstall section needs a confirmation
> > phase before beginning installation, to confirm:
> >
> > 1. That the packages which dselect intends to install are actually
> > what the user wants installed. If not, the user should be able
> > to abort the [I]nstall and go back to the main menu.
>
> You can already get this by looking at the package list, using
> [S]elect. I don't think yet another special interface for browsing
> the to-be-installed list would be helpful.
You've just said that the package list interface makes this difficult.
I had visions of a review interface which would allow deletion of
unwanted packages selected because they were recommended without
moaning about it, and would refuse to delete packages which are
dependencies of other selected packages dependent packages with
info like "X and Y depend on Z".
The current workaround solution is to keep manual notes while it
churns through a couple of hundred packages, writing down the names
of unwanted packages which are installed, and then to removing them
later. That'll work, modulo disk space constraints. It sure seems
silly, though.
> > 2. Whether a package-by-package upgrade attempt should be made
> > for every installed package, or whether this should be skipped
> > and just the packages selected for installation installed
> > (much more quickly than if all packages were looked at).
>
> This doesn't appear to make any sense. Whether upgrading or doing a
> fresh installation, dpkg processes all the available packages in turn,
> once each, and either processes it or not.
What made sense to me was to be able to select five packages and have
five packages installed without churning through two hundred packages
to do it. (A newmenu item, separate from [I]nstall, to upgrade packages
to current versions could churn through all installed packages looking
for those needing upgrade, but probably not thru all available package
files).
> I can't (won't) assume that the filenames are anything sensible.
Good point. A compromise might be to require that the initial char of
a package name match the initial char of the filename. That'd be
easy to enforce at the time of package acceptance into the distribution,
and could help a lot. Another wrinkle might be to cache package
filenames in the status file when the info is seen, and use this info
as a first trial filename when looking for the package file for a package.
If that fails, files beginning with the same initial char could be tried.
Reply to: