app-arch/unzip not in /usr/portage/profiles/base/packages

[z4]

I think there might be a small issue in /usr/portage/profiles/base/packages, in that the *app-arch/unzip atom is not listed.

app-arch/unzip is in fact installed in stage3 directly (prior to any emerge --deep --update --changed-use @world), but it is installed with "-natspec" USE flag. In fact, an emerge --ask --deep --update --changed-use app-arch/unzip does in fact want to re-emerge it, and with the "natspec" USE flag. This is all expected. Problem is, if I understand how emerge ... @world is supposed to work, it should get selected for re-emerge due to USE="natspec". But this does not happen. If, however, I put it into the @system set, which I believe is the proper spot for direct residents of stage3, then it does in fact get re-emerged properly. Otherwise, I have to wait until some other package pulls it in as a dependency, then emerge ... @world will re-emerge it. This theory that it should be part of /usr/portage/profiles/base/packages is also supported by:

[Hu]

My understanding differs. @system covers the packages that, due to being listed in the profile, can be assumed to be installed, and ebuilds can rely on their presence without explicitly BDEPENDing on it. This is why most ebuilds do not list app-arch/tar as a BDEPEND, even though most ebuilds get their sources from inside a tar archive. app-arch/unzip may be in the stage3 because the stage3 contains a package which required unzip to be present. That does not make it a system package, since stage3 is not required to be minimal. (As I understand it, stage3 is required to be useful. It does seem a bit odd if it contains packages that are immediately eligible for emerge --depclean.) I see many ebuilds do explicitly BDEPEND on unzip. Your emerge --ask --deep --update --changed-use @world should include app-arch/unzip if, and only if, a package in world depends on unzip. What does emerge --ask --verbose --depclean app-arch/unzip show? Does the result change if you add --with-bdeps=n?

I think the entry in desktop/package.use is because desktop users are expected to want natspec enabled. For other users, it will only be enabled if they pull in an ebuild that specifically requires that flag. Some do. Some do not.

[z4]

Yes, your understanding is also valid. And that is kind of what I was trying to say. There is an inconsistency. The solution is to either add *app-arch/unzip to the @system set, or remove the "app-arch/unzip natspec" from desktop/package.use.

At the moment, the first emerge ... @world does not cause unzip to be re-emerged. However, it does pull in packages that depend on unzip. Then running emerge ... @world a second time, does cause it to be re-emerged. AFAICT, it is because of the scenario I described. This does not seem consistent. Either the stage3 needs to provide the unzip package built with the USE flags it sets globally (fix the flag or fix the build), or at least call it a @system package so the first emerge ... @world can take care of it. This is already how other stage3 packages are handled. app-arch/unzip should not be treated as an exception.

[grknight]

This would depend on the stage3 used as there is no "global USE" in play here.

If a stage3 was built on a desktop profile, then yes, it will have natspec USE enabled. (Yes, I just checked a current one and it does.)

All other stage3s will not have this set because they do not include the settings in profiles/targets/desktop/package.use.

If the intention was to include it everywhere, then it can go in profiles/base/package.use or an arch specific file as necessary.
As a user, you may propose this in a bug explaining why it should be moved.

[z4]

I didn't realize about the different USE flag used in building app-arch/unzip in different stage3's. Thanks for pointing that out. So it sounds like this would be a perfect case for a profile-specific atom. I.e, all desktop profiles ".../packages" would list "app-arch/unzip" as an atom, or maybe have its own @system set that includes "*app-arch/unzip". I know that @profile sets are technically devoid of actual packages (i.e. empty), and creating/maintaining a new ".../packages" file even at a high desktop/ level is probably additional maintenance, so that won't fly...seems like the best solution is then to drop "app-arch/unzip natspec" from /usr/portage/profiles/targets/desktop. End result is that desktop stage3's are unaffected, and anyone using a desktop profile on a non-desktop stage3 would have to handle USE="natspec" for app-arch/unzip own their own. If this explanation makes sense, then there's no point in a bug report, as we'd just be shuttling a corner-case from one use-case to another. And this thread serves as documentation, so probably all good...