Ok, i'm not subscribed here so please cc me any responses directly.
Before I propose my suggestion I want to outline my issues with how meta
pkgs are done currently.
Meta pkgs by my own definition here are pkgs which have no payload of
their own, but have their "Depends" field loaded with various selected
pkgs, that dpkg and the like will ask or automatically retrieve and
install when the meta pkg is installed.
The problem #1: Because meta pkgs use the Depends field to do their job,
they are removed from the system whenever one of the pkgs they "Depend"
on is removed.
The problem #2: Meta pkgs in debian are one way. Removing a meta pkg
doesn't remove or even check for the pkgs it installed to see if they
are no longer dependent on anything or ask the user if they want to
remove them. Because of problem #1, removing a meta pkg isn't even
possible if you remove one of the pkgs it installed, because according
to the system, the meta pkg is already uninstalled.
My proposed solution is to make meta pkgs use the Suggests field instead
of the Depends field to cause frontends (dselect and i believe aptitude
already support this) to either automatically or ask the user to install
the pkgs the meta pkg is supposed to encompass. This makes just as much
sense when reading the control file as "Depends" does, and it doesn't
really break the purpose of the Suggests field, no more than using the
Depends field for meta pkgs does. But, we get around the removal of
the Meta pkg, when a pkg that was installed by it is removed, problem.
Other than using the suggests field, nothing else changes, the only real
userspace change you might want to make is to give apt-get the ability
to install suggested pkgs (which isn't a totally bad idea regardless).
(--suggest for example)
The second problem is more controversial, and a bit complex, but not
already solved mostly.
Solution #1 : apt-get has very limited removal ability compared to
something like debfoster. The patch to debfoster would be to look at
the pkg list field for the requested program to be removed and look at
it's Depends and Suggests and create a list of those pkgs that are no
longer being depended on, and allow the user to remove those it finds,
automatically or not via a switch.
Solution #2 : if we really want apt-get to remove meta pkg (it can't the
current way it's done anyway), we can use our new argument (--suggest)
with remove to tell apt-get to remove the pkgs in the "Suggests"
field. This isn't a necessary solution though, apt-get can't remove
meta pkgs now anyway, so changing meta pkgs to "Suggests" wont affect
apt-get in any way for remove.
I personally would only consider debfoster for removing meta pkgs, since
it requires some complexity for finding what's being depended on and
already has flags for not selected non-libs and such. Patching it would
be much simpler than giving debfoster's features to apt-get (something
that would be partly required to properly remove meta pkgs).
What this means :
1.We can remove pkgs that a meta pkg installs, without removing the meta
pkg (so we can later use debfoster to remove the rest, without
remembering them all).
2. By using the Suggests field in the control file for the meta pkg, we
already have out of box support for meta pkgs by dselect and aptitude.
apt-get wouldn't be that hard to patch.
3. By using the Suggests field, non-aware pkg frontends wont break,
there is no need to have them all updated at the same time, nor is there
any problem with mixed old style and new style meta pkgs. Using
suggests wont be mutually exclusive with using Depends for meta pkgs, it
just provides a way to remove pkgs it lists and still be able to remove
the rest while keeping later code to remove the meta pkg from having
dependency issues.
4. By using Suggests, we aren't reversing the dependency list when we
use a frontend (like debfoster) to remove a meta pkg. Of course this is
just semantics, but it's an important one, reversing the Depends list is
bad and could lead to problems. Reversing the suggests list means there
is no chance of circular dependency issues when removing, since the pkg
manager doesn't use suggests as a dependency during resolution.
So we basically complete the meta pkg by making it possible to remove
under all circumstances and install (install works now, without any
changes with some common pkg installers), keep everything backwards
compatible with older pkgs and pkg managing programs, keep the control
file, installing and removing logically sane and all without having to
add anything to the control file or change anything other than the
frontends (and very little there needs to be done except maybe debfoster
removal code...)
anyway, just an idea. If people like it, i'll even work out a patch for
apt-get to use suggests to install pkgs optionally, since that's a nifty
feature anyway.
--
To UNSUBSCRIBE, ema
