FS#19119 - Packages removed from a group make hard orphans
Attached to Project:
Pacman
Opened by Taylan Ulrich B. (taylanub) - Thursday, 15 April 2010, 21:24 GMT
Last edited by Allan McRae (Allan) - Sunday, 31 January 2016, 04:10 GMT
Opened by Taylan Ulrich B. (taylanub) - Thursday, 15 April 2010, 21:24 GMT
Last edited by Allan McRae (Allan) - Sunday, 31 January 2016, 04:10 GMT
|
Details
Since members of a group are "installed explicitly" (same
thing as installing each package in a group individually), a
package that was installed as a group member will appear as
"explicitly installed", even if it gets removed from its
group. We might call such packages "group orphans".
This can often be observed in the base group, where packages are apparently often removed from. We might call it a "hard [group] orphan", if such a package is not a dependency at the same time; it will actually appear to be explicitly installed, while it was installed as a group member, and is not a member of that group anymore (and probably not wanted by the user either anymore, for same reason it was removed from the group). This is seriously bad, but happens rarely. In other cases, where the package is a dependency at the same time, it will still falsely appear as an explicitly installed package, which is still bad. (This is much more often the case.) What one can do to detect group orphans, is to compare `pacman -Qe` to what is tried to be installed by `pacman -S $(cat my_package_list)`, if said person keeps a list of packages he installs when building his system anew. The person might then remove hard orphans, and manually edit the $dbpath/local/package_name/desc file of required group orphans, adding the %REASON% section (with value '1'), to properly mark them as a dependency. Obviously, this isn't nice. A possible fix would be to use the %REASON% section for a second purpose: "Installed as a group member." Then finding group orphans will be a matter of searching for packages with reason 2 and no group memberships. Although i don't know if this method is really applicable, it's just the first thing that came into mind. |
This task depends upon
Closed by Allan McRae (Allan)
Sunday, 31 January 2016, 04:10 GMT
Reason for closing: Won't implement
Additional comments about closing: No longer applies.
Sunday, 31 January 2016, 04:10 GMT
Reason for closing: Won't implement
Additional comments about closing: No longer applies.
If your favorite app is removed from base group, why should we consider it as orphan?
If your favorite app is removed from the repo, you can use -Qm switch in combination with other filter options, like -t.
"The person might then remove hard orphans, and manually edit the $dbpath/local/package_name/desc file of required group orphans, adding the %REASON% section (with value '1'), to properly mark them as a dependency.
Obviously, this isn't nice."
The next major pacman version will (probably) have a -D switch to modify %REASON% flag. See
FS#12950.To quote you:
``If your favorite app is removed from base group, why should we consider it as orphan?''
Obviously, not every package in 'base' is a favorite app of mine. But when i install that group, all packages in it are installed "as explicit", so they'll remain even if the devs remove a package because they decided it's useless.
(Repos are unrelated.)
When you install a group, you are forever stuck with that 'version' of the group (regarding `pacman -Syu`); where 'version' means what members the group has.
If i install groupX now, then the devs add package foo and remove package bar from groupX, then i do a `pacman -Syu` (which is supposed to mean "update the system"), i will NOT get 'foo' and will NOT have 'bar' removed.
(I've really never experienced a package getting new members though, having base, base-devel, and xorg installed. Hence why i didn't think of it like that before.)
Note that getting new packages of a group is as easy as reinstalling the group, but the same does not apply to packages removed from the group.
In yet other words:
# pacman -S groupX
is a *synonym* to
# pacman -S $(cat listofgroupXmembers)
One might say this is an intentional lack-of-a-feature (this being Arch Linux ;) ), but i think the way groups work at the moment is counter-intuitive, and a solution should be simple enough.
I don't see a problem with marking packages "installed as a group member" via REASON=2. For handling new group members, keep a list of installed groups, and members explicitly ignored during group installation; have `pacman -Su` use this list to update groups.
Options to other pacman operations (query, remove) will probably need to be tweaked as well, to keep up with these design changes. `-Qe` will not list group members anymore, but groups themselves, `-R` will have options to remove whole groups. In fact, groups will act much like empty packages with dependencies.
@taylanub: in your example where package "foo" is added to existing group "X" and package "bar" is removed, updating group "X" _will_ result in package "foo" being installed (explicitly) but _will not_ result in package "bar" being removed, in my experience. I agree 100% that "bar" should in fact be installed too, but is not!
Remember that when you install a group, there is nothing entered in the local pacman database to reflect that fact that you did so - instead only the packages with the corresponding %GROUPS% list defined, are installed. And %GROUPS% is set per package in the descriptor file (as opposed to a single "master" definition). This is why package "foo" will be installed (since %GROUPS% would include "X" for it) and package "bar" will not be removed (since %GROUPS% will no longer include "X" but there is _no record_ of you having installed "X" in the first place).
As far as I know, yum also works in the same way with respect to groups, but other package managers like apt and portage use metapackages instead of groups (although portage also uses "sets" which I think is largely analogous to pacman groups but still tracked independently - I stand to be corrected).
But i believe to have generalized the whole of the issue, in my comments; and have proposed a solution as well, in which i have yet to see a flaw.
Redoing a `pacman -S [--needed] groupX` will install the later added packages, but `pacman -Syu` will not.
Yes, there is nothing entered to the database about how a group was installed. If i install a single package that happens to be a groupX member, it will appear in `pacman -Qg`.
The reason package bar will not be removed is not just because there's no database entry about groupX; it's marked as "explicitly installed" (no %REASON%) anyway. Doing a `pacman -S bar` and `pacman -S groupX` (where bar is a groupX member) are the same thing, regarding the resulting desc file for bar.
I have no idea about other package managers, since my distro-specific knowledge is limited entirely to Arch Linux. I don't care about what others do, though; i can see how a clean and simple, "theoretically perfect" method to manage groups could be implemented to pacman, and we need no more IMO. --- Wait, correction: Reading comments in the other task, i realize i've reinvented a concept almost identical to what's apparently called "metapackages". =P Although i think that group members should _not_ appear as dependencies (of a 'metapackage'), and some ideas, like a list of initially ignored members, and "%REASON% 2 for 'installed as a group member'", don't seem to have been looked through yet.