Gentoo Archives: gentoo-dev

From: Pacho Ramos <pacho@g.o>
To: gentoo-dev <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] About using USE flags to pull in needed RDEPENDs being discouraged by devmanual
Date: Sun, 17 Jun 2012 11:59:12
Message-Id: 1339934243.2185.10.camel@belkin4
In Reply to: Re: [gentoo-dev] About using USE flags to pull in needed RDEPENDs being discouraged by devmanual by "Michał Górny"
1 El sáb, 16-06-2012 a las 22:36 +0200, Michał Górny escribió:
2 > On Sat, 16 Jun 2012 20:49:10 +0200
3 > Pacho Ramos <pacho@g.o> wrote:
4 >
5 > > El sáb, 16-06-2012 a las 19:07 +0200, Michał Górny escribió:
6 > > > On Sat, 16 Jun 2012 18:30:55 +0200
7 > > > Pacho Ramos <pacho@g.o> wrote:
8 > > >
9 > > > > El sáb, 16-06-2012 a las 18:09 +0200, hasufell escribió:
10 > > > > > It breaks the useflag philosophy, IMO.
11 > > > > >
12 > > > > > Useflags were meant as switches. You can turn things on and off.
13 > > > > > Pulling in optional dependencies via useflags does not allow the
14 > > > > > user to turn something off when he sets USE="-foo" emerge
15 > > > > > fuqbar. That should only be valid for virtuals or
16 > > > > > meta-packages. And that's what those are for.
17 > > > > >
18 > > > >
19 > > > > Maybe we could split them from RDEPEND to some kind of
20 > > > > EXTRA_DEPEND (or something else) to fit this purpose.
21 > > >
22 > > > There was already a lot of discussion about this and the community
23 > > > didn't care enough to agree on one of the proposed solutions. You're
24 > > > just reinventing one of them, with a new variable name and the same
25 > > > disadvantages.
26 > > >
27 > >
28 > > Do you have a link to that old thread? Because current situation of
29 > > relying on elog messages also has disadvantages
30 >
31 > http://thread.gmane.org/gmane.linux.gentoo.devel/71794
32
33 Thanks :)
34
35 From this one looks like:
36 http://article.gmane.org/gmane.linux.gentoo.devel/71889
37 http://article.gmane.org/gmane.linux.gentoo.devel/71827
38
39 are interesting approaches. Personally, SDEPEND approach looks really
40 interesting to me, maybe it's only problem would be how to explain that
41 some extra packages are needed without requiring to elog, but looks like
42 exherbo already implements a solution for this. Other think I would like
43 to see in this approach is to add a way to *globally* configure PM to
44 always accept or discard extra deps by default (even still being able to
45 configure it per package as already suggested)
46
47 > http://thread.gmane.org/gmane.linux.gentoo.devel/72162
48 >
49
50 If it's too difficult to implement first EAPI solution ok, but I really
51 would prefer the EAPI way instead of using eclass to show more postinst
52 messages instead as I really prefer this to be handled in a more
53 automatic/configurable way. Also, only packages currently needing to use
54 elog messages for this kind of problem would need to be updated to
55 latest EAPI.

Attachments

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