From: Chris Reffett <creffett@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] [PATCH] eutils.eclass: add optfeature() function
Date: Sat, 25 Jan 2014 08:09:55 -0500 [thread overview]
Message-ID: <52E3B7A3.9060409@gentoo.org> (raw)
In-Reply-To: <52E38E0A.70107@gentoo.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/25/2014 05:12 AM, Markos Chandras wrote:
> On 01/23/2014 04:48 PM, Michał Górny wrote:
>> Dnia 2014-01-23, o godz. 11:36:06 Chris Reffett
>> <creffett@gentoo.org> napisał(a):
>>
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>
>>> On 01/23/2014 11:28 AM, Michał Górny wrote:
>>>> Dnia 2014-01-23, o godz. 11:24:41 Chris Reffett
>>>> <creffett@gentoo.org> napisał(a):
>>>>
>>>>> After some discussion on good ways to communicate optional
>>>>> dependencies to users, I was shown the optfeature()
>>>>> function in net-misc/netctl. Gentoo contributor Andrew
>>>>> Hamilton and I came up with a cleaned up and expanded
>>>>> version of it, and I would like to add it to eutils.eclass
>>>>> to provide a standard way of notifying users of optional
>>>>> dependencies. The patch to eutils.eclass is attached.
>>>>
>>>> This was discussed already:
>>>>
>>>> http://thread.gmane.org/gmane.linux.gentoo.devel/72162
>>>>
>>> First of all, this is a short patch for a function, not a full
>>> eclass.
>>
>> Ah, sorry, this changes *a lot*. Let's start the bikeshed again
>> then, whatever.
>>
> I haven't looked at the implementation, but I wonder if we need a
> function for such trivial stuff. Most maintainers deal with this
> problem using pkg_postinst() einfo/elog messages. Why do we need a
> dedicated function for that? Just for consistency reasons...?
>
Consistency, and because it removes the need for a bunch of "if
has_version" lines, instead only displaying if you don't satisfy the
deps (and supports both "and" and "or" groupings for packages
satisfying the dep). This also stems from a complaint I've seen a lot
about how optional dep messages should only display if the requisite
package isn't installed, this makes that job a little simpler. But
mostly consistency, this gives us one nice function that we can
standardize on.
Chris Reffett
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iKYEARECAGYFAlLjt6NfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC
Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1SAZACgqLjfMMmvPNa/6Nwxzlpm5sde
kwQAniZMjvFkQ7H/1+wpYnDjyezplMud
=6E+E
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2014-01-25 13:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-23 16:24 [gentoo-dev] [PATCH] eutils.eclass: add optfeature() function Chris Reffett
2014-01-23 16:28 ` Michał Górny
2014-01-23 16:36 ` Chris Reffett
2014-01-23 16:48 ` Michał Górny
2014-01-25 10:12 ` Markos Chandras
2014-01-25 10:35 ` Michał Górny
2014-01-25 13:09 ` Chris Reffett [this message]
2014-01-25 13:27 ` Markos Chandras
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52E3B7A3.9060409@gentoo.org \
--to=creffett@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox