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. If @system will be removed at all, it will be much harder to perform deep and large @world updates. Practically users willing to update old systems will have to write and manage @system set on their own. Best regards, Andrew Savchenko
pgpgeWoMmmyh5.pgp
Description: PGP signature
