Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: Ian Stakenvicius <axs@g.o>
Cc: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
Date: Tue, 29 Jul 2014 04:51:30
Message-Id: 20140729065126.00886605@pomiot.lan
In Reply to: Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined by Ian Stakenvicius
1 Dnia 2014-07-28, o godz. 13:02:39
2 Ian Stakenvicius <axs@g.o> napisał(a):
3
4 > -----BEGIN PGP SIGNED MESSAGE-----
5 > Hash: SHA256
6 >
7 > On 28/07/14 07:21 AM, Michał Górny wrote:
8 > > Dnia 2014-07-25, o godz. 14:49:44 Ian Stakenvicius <axs@g.o>
9 > > napisał(a):
10 > >
11 > >> Hey all.. So, putting aside for now how much of a mess this
12 > >> would be to implement in the virtuals' ebuilds themselves, what
13 > >> do people think of changing the virtuals so that they contain an
14 > >> entry in IUSE for each provider that can satisfy it?
15 > >>
16 > >> The idea here is that the package satisfying a virtual could be
17 > >> optionally explicitly-chosen through package.use (or USE= in
18 > >> make.conf, perhaps) instead of having an entry in @world, that
19 > >> way if nothing depends on the virtual then it and the provider
20 > >> can be - --depclean'ed from the system. The idea is specifically
21 > >> NOT to have rdeps depend on these flags, that would undermine the
22 > >> whole purpose of the virtual; it would just be for end-users to
23 > >> set if they so chose.
24 > >
25 > > I think I don't get this argument.
26 > >
27 > > If you really want to have a particular provider for the virtual
28 > > for external purposes, it's fully purposeful to put it in @world
29 > > or otherwise in a custom set. In this case, USE flags aren't
30 > > helpful.
31 >
32 > The argument I was trying to make is that USE flags would allow
33 > end-users to accomplish the same thing, while not having an entry in
34 > @world and therefore allowing the package to be --depclean'ed if the
35 > virtual is --depcleaned.
36
37 If you need it externally, you need it not depcleaned, obviously. So
38 you have to have something in @world. If you need a specific
39 implementation, it's more elegant to put that in @world rather than
40 the virtual and playing with USE flags.
41
42 > > If you only prefer a particular provider, you can tip portage
43 > > easily to use it without resorting to USE flags. This also allows
44 > > portage to semi-transparently switch to other provider if
45 > > dependencies need it. In this case, USE flags only make this
46 > > auto-switching harder.
47 >
48 > That is the other part of this idea, to make auto-switching harder,
49 > because right now portage likes to auto-switch even when it seems like
50 > it shouldn't.
51
52 This is a bug in portage and should be fixed there. As I said, working
53 it around will only fix it for one package, and it will happen again
54 and again, possibly in cases harder to pinpoint.
55
56 --
57 Best regards,
58 Michał Górny

Attachments

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