Re: managing packages

[Brian May <bam@debian.org>]

>>>>> "Steve" == Steve Greenland <stevegr@debian.org> writes:

    Steve> Oh, I admit and agree that dselect is quirky and has
    Steve> problems (like the most recent attempt to remove libc6),
    Steve> but I guess my point was (IMO) complaining about apt-get
    Steve> not offering up "suggested" packages is like complaining
    Steve> that 'as' doesn't compile C code. It's not the tool for
    Steve> what you want, and no matter how crappy the C compiler,
    Steve> modifying 'as' is not the right answer. Let's fix dselect,
    Steve> or another high-level package selector/browser (which would
    Steve> *use* apt-get (or it's libraries)) to do the actual
    Steve> installation.

Agreed.

    >> - 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.

    Steve> I don't see this as a bad thing. And it's true of apt-get
    Steve> as well, isn't it? I thought dpkg was the only way to
    Steve> bypass this.

Is there any easier way to put a package on hold other then dselect?
Lately, this has been my dislike - If I just want to put one package
on hold (eg gnus as the latest version is broken), dselect demands I
fix up other dependancy problems first. Problems which according to
apt-get simply do not exist.

    >> 1. When removing or upgrading a package, apt-get automatically
    >> adds all "depends", "recommends", and "suggests" packages to a
    >> remove-list.

    Steve> 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.

    Steve> How is this different from list in 1? X depends on Y and Z,
    Steve> so all three are installed. If I remove X, Y and Z go into
    Steve> the remove-list. But Y and Z are already installed, so now
    Steve> they come back out.

Exactly. 1) lists all potential packages that might need to be
removed, wheres 2) cancels out items that where really required.

    Steve> I think all this was discussed back when apt was being
    Steve> designed. I suspect that the people involved came up with a
    Steve> workable solution. I have no idea what it was.

    Steve> So I guess I'll throw out a new algorithm:

    Steve> 1. When a user de-selects a package, all the related
    Steve> packages (depends, recommends, suggests) are considered for
    Steve> removal. If a package is not related to any other selected
    Steve> package (i.e. currently or about to be installed), it is
    Steve> also de-selected, and its related packages considered.

What about upgrades, eg if upgrading package x no longer requires
lib_old_libc5_based_library, but instead uses lib_new_libc6_based_library?

    Steve> 2. There should be a user-configurable option that
    Steve> determines whether the auto-deselection happens
    Steve> automatically, or with confirmation, or not at all.

Agreed.

    Steve> 3. We provide a "requires" package that allows the admin
    Steve> specify packages that have external (non-packaged)
    Steve> relationships. It would auto-generate a control file for a
    Steve> "psuedo-package" with the desired dependencies, and keep a
    Steve> little flatfile database of notes about *why* the package
    Steve> was required.

Would the equivs package help here? Not that I have ever used it...

    Steve> The only thing(!) the above proposal requires is an
    Steve> implementation of the depedency chaining. No new data
    Steve> structures or special flags. No mods to dpkg or apt-get.

Where would you implement this?

    >> 2. Some method to scan all packages for removal, not just the
    >> ones affected by upgrades/removals?

    Steve> We have (several?) dependency tree scanners.

We do? What packages can I find them in?

-- 
Brian May <bam@debian.org>