Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: Duncan <1i5t5.duncan@×××.net>
Cc: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: RFC: USE flags in virtuals, to allow a specific provider to be determined
Date: Sat, 26 Jul 2014 08:53:25
Message-Id: 20140726105321.7663d6bd@pomiot.lan
In Reply to: [gentoo-dev] Re: RFC: USE flags in virtuals, to allow a specific provider to be determined by Duncan <1i5t5.duncan@cox.net>
1 Dnia 2014-07-26, o godz. 08:05:32
2 Duncan <1i5t5.duncan@×××.net> napisał(a):
3
4 > Ian Stakenvicius posted on Fri, 25 Jul 2014 14:49:44 -0400 as excerpted:
5 >
6 > > Hey all.. So, putting aside for now how much of a mess this would be to
7 > > implement in the virtuals' ebuilds themselves, what do people think of
8 > > changing the virtuals so that they contain an entry in IUSE for each
9 > > provider that can satisfy it?
10 > >
11 > > The idea here is that the package satisfying a virtual could be
12 > > optionally explicitly-chosen through package.use (or USE= in make.conf,
13 > > perhaps) instead of having an entry in @world, that way if nothing
14 > > depends on the virtual then it and the provider can be - --depclean'ed
15 > > from the system. The idea is specifically NOT to have rdeps depend on
16 > > these flags, that would undermine the whole purpose of the virtual; it
17 > > would just be for end-users to set if they so chose.
18 > >
19 > > This may also help with getting portage to peg a virtual's provider to a
20 > > specific package instead of constantly trying to switch from one to
21 > > another, ie, how systemd kept getting pulled in, in relation to the
22 > > upower virtual.
23 >
24 > What about handling each such virtual_USE as a USE_EXPAND? VIRTUAL_* as
25 > reserved-namespace USE_EXPAND would give us full backward compatibility
26 > along with an immediately identifiable namespace and virtually (heh) no
27 > possibility of confusion with other configuration.
28
29 USE_EXPAND are global by definition. We ought fight with the abuse of
30 USE_EXPAND rather than make another abuse legitimate. Especially that
31 you're going to increase a lot of new variables quickly for no really
32 good reason.
33
34 --
35 Best regards,
36 Michał Górny

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies