Gentoo Archives: gentoo-dev

From: Markos Chandras <hwoarang@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [PATCH] eutils.eclass: add optfeature() function
Date: Sat, 25 Jan 2014 13:28:50
Message-Id: 52E3BBDC.4000100@gentoo.org
In Reply to: Re: [gentoo-dev] [PATCH] eutils.eclass: add optfeature() function by Chris Reffett
1 On 01/25/2014 01:09 PM, Chris Reffett wrote:
2 > On 01/25/2014 05:12 AM, Markos Chandras wrote:
3 >> On 01/23/2014 04:48 PM, Michał Górny wrote:
4 >>> Dnia 2014-01-23, o godz. 11:36:06 Chris Reffett
5 >>> <creffett@g.o> napisał(a):
6 >>>
7 >>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
8 >>>>
9 >>>> On 01/23/2014 11:28 AM, Michał Górny wrote:
10 >>>>> Dnia 2014-01-23, o godz. 11:24:41 Chris Reffett
11 >>>>> <creffett@g.o> napisał(a):
12 >>>>>
13 >>>>>> After some discussion on good ways to communicate optional
14 >>>>>> dependencies to users, I was shown the optfeature()
15 >>>>>> function in net-misc/netctl. Gentoo contributor Andrew
16 >>>>>> Hamilton and I came up with a cleaned up and expanded
17 >>>>>> version of it, and I would like to add it to eutils.eclass
18 >>>>>> to provide a standard way of notifying users of optional
19 >>>>>> dependencies. The patch to eutils.eclass is attached.
20 >>>>>
21 >>>>> This was discussed already:
22 >>>>>
23 >>>>> http://thread.gmane.org/gmane.linux.gentoo.devel/72162
24 >>>>>
25 >>>> First of all, this is a short patch for a function, not a full
26 >>>> eclass.
27 >>>
28 >>> Ah, sorry, this changes *a lot*. Let's start the bikeshed again
29 >>> then, whatever.
30 >>>
31 >> I haven't looked at the implementation, but I wonder if we need a
32 >> function for such trivial stuff. Most maintainers deal with this
33 >> problem using pkg_postinst() einfo/elog messages. Why do we need a
34 >> dedicated function for that? Just for consistency reasons...?
35 >
36 > Consistency, and because it removes the need for a bunch of "if
37 > has_version" lines, instead only displaying if you don't satisfy the
38 > deps (and supports both "and" and "or" groupings for packages
39 > satisfying the dep). This also stems from a complaint I've seen a lot
40 > about how optional dep messages should only display if the requisite
41 > package isn't installed, this makes that job a little simpler. But
42 > mostly consistency, this gives us one nice function that we can
43 > standardize on.
44 >
45 > Chris Reffett
46 >
47
48 I am fine with that especially given it's an opt-in feature.
49
50 --
51 Regards,
52 Markos Chandras