[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Meta pkgs in debian

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.

Reply to: