Gentoo Archives: gentoo-dev

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: RFC: USE flags in virtuals, to allow a specific provider to be determined
Date: Sat, 26 Jul 2014 08:06:04
Message-Id: pan$7c919$43f7e3bb$e0dbc5ae$7e640458@cox.net
In Reply to: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined by Ian Stakenvicius
1 Ian Stakenvicius posted on Fri, 25 Jul 2014 14:49:44 -0400 as excerpted:
2
3 > Hey all.. So, putting aside for now how much of a mess this would be to
4 > implement in the virtuals' ebuilds themselves, what do people think of
5 > changing the virtuals so that they contain an entry in IUSE for each
6 > provider that can satisfy it?
7 >
8 > The idea here is that the package satisfying a virtual could be
9 > optionally explicitly-chosen through package.use (or USE= in make.conf,
10 > perhaps) instead of having an entry in @world, that way if nothing
11 > depends on the virtual then it and the provider can be - --depclean'ed
12 > from the system. The idea is specifically NOT to have rdeps depend on
13 > these flags, that would undermine the whole purpose of the virtual; it
14 > would just be for end-users to set if they so chose.
15 >
16 > This may also help with getting portage to peg a virtual's provider to a
17 > specific package instead of constantly trying to switch from one to
18 > another, ie, how systemd kept getting pulled in, in relation to the
19 > upower virtual.
20
21 What about handling each such virtual_USE as a USE_EXPAND? VIRTUAL_* as
22 reserved-namespace USE_EXPAND would give us full backward compatibility
23 along with an immediately identifiable namespace and virtually (heh) no
24 possibility of confusion with other configuration.
25
26 Continuing with the earlier virtual/krb5 example, we'd have VIRTUAL_KRB5,
27 with possible settings in make.conf of:
28
29 VIRTUAL_KRB5=mit-krb5
30 VIRTUAL_KRB5=heimdal
31
32 Virtually no possibility of confusion with normal USE flags, and the
33 matching virtual would be immediately identifiable, so no possibility of
34 getting confused on what it applies to, either.
35
36 --
37 Duncan - List replies preferred. No HTML msgs.
38 "Every nonfree program has a lord, a master --
39 and if you use the program, he is your master." Richard Stallman

Replies