Historical bug tracker for the Pacman package manager.

The pacman bug tracker has moved to gitlab:

This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.

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
Task Type Feature Request
Category System
Status Closed
Assigned To No-one
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 4
Private No


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.
Comment by Nagy Gabor (combo) - Wednesday, 28 April 2010, 15:40 GMT
Could you provide an example, please? I am not sure I completely understand what you mean on group orphans.
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 .
Comment by Taylan Ulrich B. (taylanub) - Thursday, 29 April 2010, 12:09 GMT
When you install a group, it is equivalent to installing all packages in that group one by one; they are marked "explicitly installed". Now, if you really individually know each package in the group and know you want them, then OK, but that's not likely the case. For example i'm clueless on most packages in 'base', and i'm sure it's the same with many people. So when the devs remove package 'foo' from base, say because they realized not everyone needs it, your installation will not be affected by this and that package 'foo' will forever be installed in your system, marked "explicitly installed".

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.)
Comment by Taylan Ulrich B. (taylanub) - Saturday, 01 May 2010, 09:00 GMT
Here's another way to look at it:
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.
Comment by Craig King (kingc) - Tuesday, 11 May 2010, 11:44 GMT
This is essentially a duplicate of FS#8242 isn't it?

@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).
Comment by Taylan Ulrich B. (taylanub) - Tuesday, 11 May 2010, 15:23 GMT
Yes, at its core it is a duplicate of that task.
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.
Comment by Allan McRae (Allan) - Sunday, 31 January 2016, 04:09 GMT
I think this bug is obsolete now - you can select exactly what packages you want from a group at install time. The means an explicitly installed package is by choice.