On 11/14/2014 06:14 AM, Andrew Savchenko wrote: > Hi, > > On Fri, 14 Nov 2014 07:20:50 -0500 Anthony G. Basile wrote: >> On 11/13/14 23:15, Zac Medico wrote: >>> On 11/13/2014 08:01 PM, Rich Freeman wrote: >>>> On Thu, Nov 13, 2014 at 9:38 PM, Michael Palimaka <kensing...@gentoo.org> >>>> wrote: >>>>> On 14/11/14 11:06, Rich Freeman wrote: >>>>>> Well, the idea would be to maintain the virtual INSTEAD of @system, or >>>>>> have @system just pull in the virtual and make some arch-specific >>>>>> additions. >>>>> Will that work? Some profiles remove packages from the base @system and >>>>> replace it with their own implementations (eg. BSD). >>>> Maybe. The thing is that a package either depends on something or it >>>> doesn't. If it really does depend on something, then the fact that it >>>> isn't available on BSD/etc isn't going to magically make the package >>>> work. We just loosely define system dependencies in a way that makes >>>> them work 98% of the time, basically accepting that things are going >>>> to break and we get away with it because few of our users actually run >>>> on BSD/etc. >>>> >>>> If it is just a matter of preference then a profile could install an >>>> alternative package that is in a virtual. However, this won't work if >>>> everybody still uses some convenience virtual that pulls in bash/etc >>>> and the BSD folks don't want to install bash unnecessarily. >>> Maybe I'm missing something, but if you are using virtuals, then you can >>> make the deps conditional on profile forced/masked flags like >>> userland_BSD and userland_GNU if necessary. These behave like normal USE >>> flags, aside from the fact the they are forced or masked by profiles. >> >> Sorry Zac, I posted my reply before I read this. This is essentially >> the point I was making. However, I think this will be cumbersome. With >> the current way we do things, its easy to delete packages from @system >> by just doing '-*sys-apps/man-pages' (for example) in a profile's >> packages file. It is not so easy to delete from a DEPEND string, so I >> foresee some tricky if logic here. > > There is another drawback of using virtuals instead of @system set. > For old systems (in practical terms they are systems not updated > @world for more than several month) it is wise to update kernel, > @system and only afterwards whole @world. > > Virtuals will not catch updates in underlying packages if --deep is > not used and it can't be used, because some packages from @system > may indirectly depend on packages from @world (e.g. cairo, qt or > xorg) which will trigger half of the @world update with -D @system > which makes it impossible and impractical to use -D @system before > full @world update on old setups. > > We already have this problem with virtua/libc: it is not updated at > all, so when I run emerge -uav @system for the purposes described > above I have to manually add sys-devel/glibc to the list.
There was a time long ago when portage actually behaved the way you want here. I implemented the behavior myself, but then I changed it to the way it is now because others complained that "virtuals should behave just like normal packages." We could certainly add an emerge option which would trigger the behavior that you want. -- Thanks, Zac
