Re: managing packages
On 28-Jan-00, 22:47 (CST), Brian May <bam@debian.org> wrote:
> >>>>> "Steve" == Steve Greenland <stevegr@debian.org> writes:
> The problem with dselect, is often it it very difficult to get
> dependancies correct, as (it is several weeks since a last used it so
> I have forgotten the details):
Oh, I admit and agree that dselect is quirky and has problems (like the
most recent attempt to remove libc6), but I guess my point was (IMO)
complaining about apt-get not offering up "suggested" packages is like
complaining that 'as' doesn't compile C code. It's not the tool for what
you want, and no matter how crappy the C compiler, modifying 'as' is
not the right answer. Let's fix dselect, or another high-level package
selector/browser (which would *use* apt-get (or it's libraries)) to do
the actual installation.
> - even if I just want to install one package, eg gimp, I have to fix
> up the dependancies for the rest of the system first.
I don't see this as a bad thing. And it's true of apt-get as well, isn't
it? I thought dpkg was the only way to bypass this.
> 1. When removing or upgrading a package, apt-get automatically adds
> all "depends", "recommends", and "suggests" packages to a remove-list.
Okay...
> 2. For every package about to be installed (including upgrades) or
> already installed, apt-get removes any packages listed in "depends",
> "recommends" or "suggests" from the remove-list.
How is this different from list in 1? X depends on Y and Z, so all three
are installed. If I remove X, Y and Z go into the remove-list. But Y and
Z are already installed, so now they come back out.
I think all this was discussed back when apt was being designed. I
suspect that the people involved came up with a workable solution. I
have no idea what it was.
So I guess I'll throw out a new algorithm:
1. When a user de-selects a package, all the related packages (depends,
recommends, suggests) are considered for removal. If a package is not
related to any other selected package (i.e. currently or about to be
installed), it is also de-selected, and its related packages considered.
2. There should be a user-configurable option that determines whether
the auto-deselection happens automatically, or with confirmation, or not
at all.
3. We provide a "requires" package that allows the admin specify
packages that have external (non-packaged) relationships. It would
auto-generate a control file for a "psuedo-package" with the desired
dependencies, and keep a little flatfile database of notes about *why*
the package was required.
The only thing(!) the above proposal requires is an implementation of
the depedency chaining. No new data structures or special flags. No mods
to dpkg or apt-get.
> 2. Some method to scan all packages for removal, not just the ones
> affected by upgrades/removals?
We have (several?) dependency tree scanners.
--
Steve Greenland <vmole@swbell.net>
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)
Reply to: