|
Home > Archive > Debian Developers > January 2006 > Meta pkgs in debian
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Meta pkgs in debian
|
|
| Ed Sweetman 2006-01-22, 8:58 pm |
| 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, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Tino Keitel 2006-01-23, 7:53 am |
| On Sun, Jan 22, 2006 at 20:31:53 -0500, Ed Sweetman wrote:
> 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.
[...]
> 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
Aptitude does this per default.
Regards,
Tino
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Ed Sweetman 2006-01-23, 6:14 pm |
|
>On Sun, Jan 22, 2006 at 20:31:53 -0500, Ed Sweetman wrote:
>
>
>
>[...]
>
>
>
>
>Aptitude does this per default.
>
So does debfoster, but how can aptitude remove the meta package, and
attempt to remove all the pkgs that were installed because of it, when
you removed one of those pkgs yourself before and that caused the pkg
manager to remove the meta pkg.
say you installed mymetapkg. mymetapkg installs something the
maintainer thought was really useful to it, but not interdependent with
the rest of the pkgs. Now you decide you dont want that nifty pkg that
got installed when you installed mymetapkg, you remove it. pkg manager
removes the pkg "mymetapkg" too because it depends on that nifty other
pkg. Now a while later you decide you dont want mymetapkg because you
hate it or whatever, now what do you do? Reinstall the mymetapkg pkg to
remove it? Using the Suggests field instead of Depends ensures this is
never a problem. It fixes every issue there is with having meta pkgs
use dependencies to get the other pkgs installed, without any drawbacks.
aptitude can't do this. so saying this is something aptitude can do is
completely wrong. If the pkg isn't installed, aptitude doesn't respond
with any action when asked to remove it.
It just doesn't make as much sense to use depends than suggests..
aptitude already supports installing/retrieving via suggests, removing
those installed real pkgs wouldn't remove the meta pkg with suggests,
where as in depends it does. This makes removal of the meta pkg
possible (and it's installed pkgs) a much more straightforward and
logical process later on, no regexps or state juggling or black magic is
required. only the "simple" feature of removing suggested pkgs,
perhaps via an argument/option similar to the one used to install
suggested pkgs.
Suggests solves this annoying issue with meta pkgs with extremely minor
changes to the way the pkgs are made (s/Depends/Suggests) and for
removal, an argument/option that's selectable to tell aptitude to try
removing suggested pkgs in the given pkg if they're installed.
Oh, and if i'm missusing Suggests when in fact, aptitude uses Recommends
to install non-"depends" pkgs, then replace all my usages of Suggests
with Recommends.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|