Hi since last update to portage-2.1.2-r9 , it behavior strangely changed, when trying to emerge virtual package portage also want to re-emerge all virtual package direct dependencies ,even if they are already installed. why? What even worse is then i use the --nodeps portage just ignores this For example: ----------------------------------------------- #emerge -pv --oneshot --nodeps perl-libnet These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] dev-lang/perl-5.8.8-r2 USE="gdbm -berkdb -build -debug -doc -ithreads -perlsuid" 0 kB [ebuild R ] virtual/perl-libnet-1.19 0 kB Total: 2 packages (2 reinstalls), Size of downloads: 0 kB ------------------------------------------------------- What the hell for does it need to re-emerge perl? While previously it was (even without the --nodeps flag) ------------------------------------------------------- emerge -pv --nodeps perl-libnet These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] virtual/perl-libnet-1.19 0 kB Total size of downloads: 0 kB ------------------------------------------------------- Although i can PARTLY see the reasoning for such portage behavior change ,like a version of virtual is bumped only then one of it's direct dependencies is also bumped, and there should be no need to rebuild the same version of virtual package. Still what if ,for example, i just emerge -C virtual/somepkg and then emerge it again there is no need to re-emerge its dependencies. So even if you don't want to change back portage behaviour , PLEASE PLEASE PLEASE at least make portage respect the --nodeps for virtuals. This is very important to me. Thanks Reproducible: Always Steps to Reproduce: 1.re-emerge same version of virtual package with already emerge dependencies. 2.Happens even with --nodeps flag 3. Actual Results: #emerge -pv --oneshot --nodeps perl-libnet These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] dev-lang/perl-5.8.8-r2 USE="gdbm -berkdb -build -debug -doc -ithreads -perlsuid" 0 kB [ebuild R ] virtual/perl-libnet-1.19 0 kB Total: 2 packages (2 reinstalls), Size of downloads: 0 kB Expected Results: #emerge -pv --nodeps perl-libnet These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] virtual/perl-libnet-1.19 0 kB Total size of downloads: 0 kB
The virtual/* packages (new-style virtuals) now behave more like old-style virtuals as part of the fix for bug #141118. For example, if virtual/perl-libnet was an old-style virtual, you'd get similar behavior. `emerge virtual/perl-libnet` would pull in dev-lang/perl-5.8.8-r2 without the additional virual ebuild, since old-style virtuals are implemented slightly differently (via PROVIDE). I think the current behavior is fine. If you want to reinstall a new-style virtual, it can be done like this: emerge --unmerge =virtual/perl-libnet-1.19 emerge --noreplace =virtual/perl-libnet-1.19
I think that emerge --unmerge =virtual/perl-libnet-1.19 emerge --noreplace =virtual/perl-libnet-1.19 is a dirty hack I ,as well as ALL other people i've asked, think that this portage behavior is wrong. At least don't you think the following is bizarre? ---------------(1)----------------- # emerge -pv virtual/x11 These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] x11-apps/xrdb-1.0.2 USE="-debug" 0 kB [ebuild R ] app-text/rman-3.2 0 kB [ebuild R ] x11-misc/makedepend-1.0.0 USE="-debug" 0 kB [ebuild R ] x11-themes/gentoo-xcursors-0.3.1 0 kB [ebuild R ] virtual/x11-7.0-r2 USE="dri" 0 kB [ebuild R ] x11-apps/xdriinfo-1.0.1 USE="-debug" 0 kB [ebuild R ] x11-misc/imake-1.0.2 USE="-debug" 0 kB [ebuild R ] x11-libs/libXvMC-1.0.2 USE="-debug" 0 kB [ebuild R ] x11-libs/libXprintAppUtil-1.0.1 USE="-debug" 0 kB [ebuild R ] x11-apps/xsetroot-1.0.1 USE="-debug" 0 kB [ebuild R ] x11-themes/xcursor-themes-1.0.1 USE="-debug" 0 kB [ebuild R ] x11-base/xorg-x11-7.1 0 kB [ebuild R ] x11-apps/xdpyinfo-1.0.1 USE="-debug" 0 kB [ebuild R ] x11-libs/libXevie-1.0.1 USE="-debug" 0 kB [ebuild R ] x11-libs/libXTrap-1.0.0 USE="-debug" 0 kB [ebuild R ] x11-apps/xdm-1.0.5 USE="pam xprint -debug -ipv6" 0 kB [ebuild R ] x11-libs/libFS-1.0.0 USE="-debug -ipv6" 0 kB [ebuild R ] x11-libs/liboldX-1.0.1 USE="-debug" 0 kB [ebuild R ] x11-misc/gccmakedep-1.0.2 USE="-debug" 0 kB Total: 19 packages (19 reinstalls), Size of downloads: 0 kB -------------------------------- Now consider this: ----------------(2)---------------- #env USE="-dri" emerge -pv virtual/x11 These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] x11-apps/xrdb-1.0.2 USE="-debug" 0 kB [ebuild R ] app-text/rman-3.2 0 kB [ebuild R ] x11-misc/makedepend-1.0.0 USE="-debug" 0 kB [ebuild R ] x11-themes/gentoo-xcursors-0.3.1 0 kB [ebuild R ] virtual/x11-7.0-r2 USE="-dri*" 0 kB [ebuild R ] x11-misc/imake-1.0.2 USE="-debug" 0 kB [ebuild R ] x11-libs/libXvMC-1.0.2 USE="-debug" 0 kB [ebuild R ] x11-libs/libXprintAppUtil-1.0.1 USE="-debug" 0 kB [ebuild R ] x11-apps/xsetroot-1.0.1 USE="-debug" 0 kB [ebuild R ] x11-themes/xcursor-themes-1.0.1 USE="-debug" 0 kB [ebuild R ] x11-base/xorg-x11-7.1 0 kB [ebuild R ] x11-apps/xdpyinfo-1.0.1 USE="-debug" 0 kB [ebuild R ] x11-libs/libXevie-1.0.1 USE="-debug" 0 kB [ebuild R ] x11-libs/libXTrap-1.0.0 USE="-debug" 0 kB [ebuild R ] x11-apps/xdm-1.0.5 USE="pam xprint -debug -ipv6" 0 kB [ebuild R ] x11-libs/libFS-1.0.0 USE="-debug -ipv6" 0 kB [ebuild R ] x11-libs/liboldX-1.0.1 USE="-debug" 0 kB [ebuild R ] x11-misc/gccmakedep-1.0.2 USE="-debug" 0 kB Total: 18 packages (18 reinstalls), Size of downloads: 0 kB -------------------------------- but with --newuse ---------------(3)----------------- # env USE="-dri" emerge -pv --newuse virtual/x11 These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] virtual/x11-7.0-r2 USE="-dri*" 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB -------------------------------- Only (3) is a correct behavior. Could you please explain what was wrong in the old portage behavior? And why you consider the new unlogical(at least from portage enduser point of view) behavior correct?
Virtual ebuilds serve a layer of indirection in dependencies. As such, it may make sense for them to behave differently from regular ebuilds that actually install something. The virtual/x11 ebuild is a very special case. It was only created as a compatibility hack for the transition from monolithic X to modular X. Eventually, the virtual/x11 ebuild is supposed to be removed from the tree (and not a moment too soon, IMO). AFAIK, virtual/x11 is the only virtual ebuild that "supports" USE flags, but I think it's questionable whether or not USE flags should be allowed for virtuals.
(In reply to comment #3) LEAVING ALL PHILOSOPHY ASIDE, THE ONLY FACT THAT ALREADY EMERGED PACKAGES WOULD BE REBUILDED IN VAIN, SHOW THIS BEHAVIOR IS NOT CORRECT. In spite of that there should be no real need to rebuild same versions of already installed virtuals, unless one of its provider dependencies were unmerged from the system. BUT this is already a philosophy, in real world anything may happen :) and virtuall/x11 is one example of that, or some one just wanting for no special reason to reinstall virtual pkg. Another example would be my personal special use of the old behavior. So please at least make portage respect the --nodeps flag for virtuals. > Virtual ebuilds serve a layer of indirection in dependencies. As such, it may > make sense for them to behave differently from regular ebuilds that actually > install something. > > The virtual/x11 ebuild is a very special case. It was only created as a > compatibility hack for the transition from monolithic X to modular X. > Eventually, the virtual/x11 ebuild is supposed to be removed from the tree (and > not a moment too soon, IMO). AFAIK, virtual/x11 is the only virtual ebuild > that "supports" USE flags, but I think it's questionable whether or not USE > flags should be allowed for virtuals. > I agree with this, still it does not explain why new behavior is better than old. On the contrary my examples show the old behavior is better: more efficient .more logical, more expected at least with the --nodeps flag. So what are the actual benefits of new behavior? Also why with the new portage the commands: #env USE="-dri" emerge -pv virtual/x11 #env USE="-dri" emerge -pv --newuse virtual/x11 do not produce same results, this is 100% not logical according to new behavior. the --newuse should make the portage more greedy in wanting to re-emerge pkgs :) Thanks
(In reply to comment #4) > So what are the actual benefits of new behavior? It's a side effect from the implementation details of bug #141118 and I still haven't seen a compelling reason to change the current behavior. > Also why with the new portage the commands: > #env USE="-dri" emerge -pv virtual/x11 > #env USE="-dri" emerge -pv --newuse virtual/x11 > do not produce same results, this is 100% not logical according to new > behavior. > the --newuse should make the portage more greedy in wanting to re-emerge pkgs As said in Comment #3, the idea of supporting USE flags for virtuals is questionable. The only ebuild that does it is virtual/x11-7.0-r2 that ebuild has always acted as a substitute for proper specification of modular deps. It's really a poor example of a virtual ebuild and should be removed from the tree ASAP.
I have to agree that this is a step backwards. Going by glep 37 new-style virtuals should be just like any other ebuild. Also bug #141118 seems like a poor reason for this behavior (transition issue, workaround exists). If consistency is the goal I'd rather have old-style virtuals adjusted, I think that would be less irritating.
(In reply to comment #6) > I have to agree that this is a step backwards. Going by glep 37 new-style > virtuals should be just like any other ebuild. glep 37 was written before the transition to new-style virtuals and at that time it was impossible to foresee all implications of the transition. > Also bug #141118 seems like a > poor reason for this behavior (transition issue, workaround exists). How is it a transitional issue? The idea is that the resolver should recognize which virtual choices are easiest to satisfy. > If > consistency is the goal I'd rather have old-style virtuals adjusted, I think > that would be less irritating. The new behavior came from the implementation details and it seemed to be an acceptable side-effect. If there is a clean an simple way to change the behavior then to be more consistent with normal ebuilds then that's fine with me. However, if that means making bug #141118 a WONTFIX then I think you'll have to justify it to the people CC'd on that bug.
(In reply to comment #7) > If there is a clean an simple way to change the > behavior then to be more consistent with normal ebuilds then that's fine with > me. I should also note that I'm planning to rewrite the resolver soon. It shouldn't be any trouble to fix both this bug and bug #141118 simultaneously and cleanly with an new resolver. This bug just doesn't seem worth making an effort to solve at this particular moment given that it doesn't seem to bother many people.
(In reply to comment #7) > (In reply to comment #6) > > I have to agree that this is a step backwards. Going by glep 37 new-style > > virtuals should be just like any other ebuild. > > glep 37 was written before the transition to new-style virtuals and at that > time it was impossible to foresee all implications of the transition. Heh, I knew there was a reason why I didn't like this GLEP ;) And this particular implication wasn't exactly unpredictable when the GLEP was written and accepted. > > Also bug #141118 seems like a > > poor reason for this behavior (transition issue, workaround exists). > > How is it a transitional issue? The idea is that the resolver should recognize > which virtual choices are easiest to satisfy. Ok, maybe that statement was a bit too quick (thought it was just an issue for people who got the jdk via old-style virtual, just realized that it also applies to people who installed the jdk directly). As for the idea, I'm not sure that I like it. It pretends to know the "cost" of a package and put a metric on it with cost(virtual) < cost(non-virtual). If you want to go that way should just do it in an obvious way and not hide it behind category == "virtual". But I think it's not necessary anyway, I think we should use the existing PROVIDE field to automatically pull the virtual in, e.g. PROVIDE=virtual/jdk => PDEPEND=virtual/jdk more or less, rather than implementing irritating special cases into the dep resolver. > > If > > consistency is the goal I'd rather have old-style virtuals adjusted, I think > > that would be less irritating. > > The new behavior came from the implementation details and it seemed to be an > acceptable side-effect. If there is a clean an simple way to change the > behavior then to be more consistent with normal ebuilds then that's fine with > me. However, if that means making bug #141118 a WONTFIX then I think you'll > have to justify it to the people CC'd on that bug. Didn't consider it as WONTFIX, rather as WORKSFORME ;) You might label the old behavior as a regression, I'd consider the new behavior as a regression. But see above for an IMO cleaner solution (don't know if it's viable, you know I like to stay away from the resolver code).
(In reply to comment #9) > But I think it's not necessary anyway, I think we > should use the existing PROVIDE field to automatically pull the virtual in, > e.g. PROVIDE=virtual/jdk => PDEPEND=virtual/jdk more or less, rather than > implementing irritating special cases into the dep resolver. It would need to specify which version it provides, since there are several slots of virtual/jdk. If you don't like the special case for the virtual category, I think it would be better to mark them with some metadata. However, we already know that all the ebuilds in the virtual/ category will have that mark. > Didn't consider it as WONTFIX, rather as WORKSFORME ;) You might label the old > behavior as a regression, I'd consider the new behavior as a regression. But > see above for an IMO cleaner solution (don't know if it's viable, you know I > like to stay away from the resolver code). Perhaps the current behavior is a regression. I never said that it wasn't. ;) It just seems to me that it works well enough for now in all important use cases. Like I said comment #8, we can solve both bugs cleanly with a new resolver. The current behavior seems acceptable to me for the time being (though certainly not ideal).
(In reply to comment #8) > I should also note that I'm planning to rewrite the resolver soon. It > shouldn't be any trouble to fix both this bug and bug #141118 simultaneously > and cleanly with an new resolver. This bug just doesn't seem worth making an > effort to solve at this particular moment given that it doesn't seem to bother > many people. > Then could fix at least that if --nodeps flag is specified, it would NOT trigger the emerge of direct dependencies of virtual and rebuild only the virtual itself, in the current branch?
Created attachment 110489 [details, diff] make --nodeps behave like a normal package for new-style virtuals (In reply to comment #11) > Then could fix at least that if --nodeps flag is specified, it would NOT > trigger the emerge of direct dependencies of virtual and rebuild only the > virtual itself, in the current branch? This patch will do the trick. It will be included in 2.1.2-r10.
(In reply to comment #12) > This patch will do the trick. It will be included in 2.1.2-r10. Thanks a lot.
This has been released in 2.1.2-r10.
