Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: Ian Stakenvicius <axs@g.o>
Cc: gentoo-dev <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
Date: Mon, 28 Jul 2014 11:21:21
Message-Id: 20140728132118.0c421aeb@pomiot.lan
In Reply to: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined by Ian Stakenvicius
1 Dnia 2014-07-25, o godz. 14:49:44
2 Ian Stakenvicius <axs@g.o> napisał(a):
3
4 > Hey all.. So, putting aside for now how much of a mess this would be
5 > to implement in the virtuals' ebuilds themselves, what do people think
6 > of changing the virtuals so that they contain an entry in IUSE for
7 > each provider that can satisfy it?
8 >
9 > The idea here is that the package satisfying a virtual could be
10 > optionally explicitly-chosen through package.use (or USE= in
11 > make.conf, perhaps) instead of having an entry in @world, that way if
12 > nothing depends on the virtual then it and the provider can be
13 > - --depclean'ed from the system. The idea is specifically NOT to have
14 > rdeps depend on these flags, that would undermine the whole purpose of
15 > the virtual; it would just be for end-users to set if they so chose.
16
17 I think I don't get this argument.
18
19 If you really want to have a particular provider for the virtual for
20 external purposes, it's fully purposeful to put it in @world or
21 otherwise in a custom set. In this case, USE flags aren't helpful.
22
23 If you only prefer a particular provider, you can tip portage easily to
24 use it without resorting to USE flags. This also allows portage to
25 semi-transparently switch to other provider if dependencies need it.
26 In this case, USE flags only make this auto-switching harder.
27
28 > This may also help with getting portage to peg a virtual's provider to
29 > a specific package instead of constantly trying to switch from one to
30 > another, ie, how systemd kept getting pulled in, in relation to the
31 > upower virtual. Note - I haven't done any tests to determine if this
32 > actually helps with such issues tho (or even attempted to reproduce
33 > them, as i was apparently one of the lucky ones that it didn't happen to).
34
35 While I agree that finding some solution is a good step forward, I'm
36 afraid this doesn't really lead us anywhere. Even if it allows to
37 workaround the actual portage issue, I'm afraid we will hit it again
38 somewhere else. Shortly, Gentoo would be full of workarounds... oh
39 wait, it already is.
40
41 By the way, proper virtuals for krb5 would involve much more crazy
42 stuff to get slot operator right. And then Ciaran would yell at us for
43 abusing slots.
44
45 --
46 Best regards,
47 Michał Górny

Attachments

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

Replies