[gentoo-dev] [PATCH] eutils.eclass: add optfeature() function
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello all,
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.
Chris Reffett
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iKYEARECAGYFAlLhQklfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC
Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1TDkwCeJ7MQliIiI6ViSkZzD+eIYM/J
0F4AoIVMP32HenJcjOkTIJkd6vGniiSi
=+oIe
-END PGP SIGNATURE-
--- eutils.eclass 2014-01-22 23:36:35.81900 -0500
+++ eutils.eclass.patched 2014-01-23 00:37:07.90700 -0500
@@ -1729,4 +1729,49 @@
check_license() { die you no longer need this as portage supports ACCEPT_LICENSE itself; }
+# @FUNCTION: optfeature
+# @USAGE: short description package atom to match [other atoms]
+# @DESCRIPTION:
+# Print out a message suggesting an optional package (or packages) which
+# provide the described functionality
+#
+# The following snippet would suggest app-misc/foo for optional foo support,
+# app-misc/bar or app-misc/baz[bar] for optional bar support
+# and either both app-misc/a and app-misc/b or app-misc/c for alphabet support.
+# @CODE:
+# optfeature foo support app-misc/foo
+# optfeature bar support app-misc/bar app-misc/baz[bar]
+# optfeature alphabet support app-misc/a app-misc/b app-misc/c
+#
+optfeature() {
+ debug-print-function ${FUNCNAME} $@
+ local i j msg
+ local desc=$1
+ local flag=0
+ shift
+ for i; do
+ for j in $i; do
+ if has_version $j; then
+flag=1
+ else
+flag=0
+break
+ fi
+ done
+ if [[ $flag -eq 1 ]]; then
+ break
+ fi
+ done
+ if [[ $flag -eq 0 ]]; then
+ for i; do
+ msg=
+ for j in $i; do
+msg=${msg} ${j} and
+ done
+ msg=${msg:0: -4} for ${desc}
+ elog ${msg}
+ done
+ fi
+}
+
fi
Re: [gentoo-dev] [PATCH] eutils.eclass: add optfeature() function
Dnia 2014-01-23, o godz. 11:24:41 Chris Reffett creff...@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 -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] eutils.eclass: add optfeature() function
-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 creff...@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. Further, people are doing this sort of thing already (printing messages to say if you want support for x, install y, this is just making it easier to do so. Of course full support for an SDEPEND variable would be much better, but unless you have a patch for that ready to go for the next EAPI I don't see that happening anytime soon, so a short function in eutils seems like a reasonable choice to me. Chris Reffett -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlLhRPZfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1QaawCeM3GnYAc83Czei2r1l2XHFFB4 sAgAn21yARrui9E+ZsNnk75UCk0j0oEp =VTT0 -END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH] eutils.eclass: add optfeature() function
Dnia 2014-01-23, o godz. 11:36:06 Chris Reffett creff...@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 creff...@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. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Re: rfc: revisiting our stabilization policy
On Mon, Jan 20, 2014, Tom Wijsman wrote: On Sun, 19 Jan 2014, Christopher Head wrote: If stable really is falling behind and the backlog is always growing, obviously something has to be done. I just don't want something to mean don't have a stable tree. The stable tree provides me with a benefit. If standards have to slip a bit to maintain timeliness, then I'd prefer a stable tree that's as stable as practical, accepting reality-- perhaps where users are able to submit reports of working packages, or where we let platform-agnostic packages be stabilized after one arch has tested, or various of the other suggestions in this thread. Just not no stable tree at all. +1 as long as we can find effort and ways to keep it around. What? Without a stable tree, Gentoo is useless afaic. I don't think that's what was being proposed, though. The question was really the old complaint about slow architectures; the -* arch solution sounds like the most reasonable definition of dropping keywords, in the absence of AT communication otherwise. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy
On Thu, 23 Jan 2014 18:12:42 + Steven J. Long sl...@rathaus.eclipse.co.uk wrote: On Mon, Jan 20, 2014, Tom Wijsman wrote: On Sun, 19 Jan 2014, Christopher Head wrote: If stable really is falling behind and the backlog is always growing, obviously something has to be done. I just don't want something to mean don't have a stable tree. The stable tree provides me with a benefit. If standards have to slip a bit to maintain timeliness, then I'd prefer a stable tree that's as stable as practical, accepting reality-- perhaps where users are able to submit reports of working packages, or where we let platform-agnostic packages be stabilized after one arch has tested, or various of the other suggestions in this thread. Just not no stable tree at all. +1 as long as we can find effort and ways to keep it around. What? Without a stable tree, Gentoo is useless afaic. It moves us closer to upstream releases, a little more bleeding edge; a lot of users and developers run that already, it is found to be useful. I don't think that's what was being proposed, though. The question was really the old complaint about slow architectures; the -* arch solution sounds like the most reasonable definition of dropping keywords, in the absence of AT communication otherwise. Dropping keywords and specifying -* are a world apart of each other. The former means that it is not ready for wide stable or testing users, the latter means that it has been tested to not work at all; furthermore, we need to explicitly specify which arches in that case. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy
On Thu, 2014-01-23 at 20:13 +0100, Tom Wijsman wrote: I don't think that's what was being proposed, though. The question was really the old complaint about slow architectures; the -* arch solution sounds like the most reasonable definition of dropping keywords, in the absence of AT communication otherwise. Dropping keywords and specifying -* are a world apart of each other. The former means that it is not ready for wide stable or testing users, the latter means that it has been tested to not work at all; furthermore, we need to explicitly specify which arches in that case. The complaint is slow to stable arches - by specifying -* arch it would signify that ONLY that arch uses that version of the ebuild - and it would be up to the arch team to remove it once they've stabled the new version - and considering the complaint is only about slow arches, there's nothing additional to specify in there - it's REMOVING arches that have stabled a newer version already, so they are unaffected. On the other hand, you're suggesting that we don't actually bother with stabling things - or actually testing that things are properly stable, allowing anyone to decide when something is stable, whether they have access to the hardware to actually test that it works. You and a few others keep talking in the theoretical while I've shown an actual problem but you and the others conveniently ignore ACTUAL problems in favor of your possible problems. Please stop.
Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy
On Thu, 23 Jan 2014 14:55:34 -0600 Steev Klimaszewski st...@gentoo.org wrote: On Thu, 2014-01-23 at 20:13 +0100, Tom Wijsman wrote: The complaint is slow to stable arches Yes. by specifying -* arch it would signify that ONLY that arch uses that version of the ebuild - and it would be up to the arch team to remove it once they've stabled the new version - and considering the complaint is only about slow arches, there's nothing additional to specify in there - it's REMOVING arches that have stabled a newer version already, so they are unaffected. As this is a suggestion that is made by someone else, whom I have already replied to stating this is a world apart from the discussion in this thread; I am skipping this entire paragraph, I think you meant to send the reply to the other person with his/her post as In-Reply-To. On the other hand, you're suggesting that we don't actually bother with stabling things or actually testing that things are properly stable, allowing anyone to decide when something is stable, whether they have access to the hardware to actually test that it works. This is missing reference, and thus I doubt if that is my suggestion. Looking back at the entire context of this thread, I have made several ideas as various options; which was done as to feed the discussion to consider several viewpoints. You and a few others keep talking in the theoretical This thread is based on an actual problem. while I've shown an actual problem but you and the others conveniently ignore ACTUAL problems in favor of your possible problems. Please stop. Well, as seen on #gentoo-dev you shoot down solutions. Please consider. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy
Tom Wijsman wrote: you shoot down solutions Maybe it wasn't a very good solution that deserved to be shot down. //Peter pgpWdBSgiDfHp.pgp Description: PGP signature
Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy
On Thu, 23 Jan 2014 23:42:28 +0100 Peter Stuge pe...@stuge.se wrote: Tom Wijsman wrote: you shoot down solutions Maybe it wasn't a very good solution that deserved to be shot down. Maybe it was; what is needed here, is the feedback that makes it better. Work towards a very good solution deserves more than a plain /dev/null; if they end up in /dev/null when provided, solutions appear unwelcome. Constructivism has to come from both sides to have an useful discussion. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy
On Fri, 2014-01-24 at 00:50 +0100, Tom Wijsman wrote: On Thu, 23 Jan 2014 23:42:28 +0100 Peter Stuge pe...@stuge.se wrote: Tom Wijsman wrote: you shoot down solutions Maybe it wasn't a very good solution that deserved to be shot down. Maybe it was; what is needed here, is the feedback that makes it better. Work towards a very good solution deserves more than a plain /dev/null; if they end up in /dev/null when provided, solutions appear unwelcome. Constructivism has to come from both sides to have an useful discussion. Your suggestion was expanding the arm keyword to armv4-linux, armv5-linux, armv6-linux, armv6-hardfloat-linux, armv7-softfp-linux, armv7-hardfloat-linux, armv7-hardfloat-uclibc-linux - that is nowhere near a good solution. The /dev/null comment was about wanting others to do the work and not contributing anything more than (imo) a stupid idea - if you aren't willing to put in the work, don't expect others to. And yes, I see what you mean now re: my reply seeming off - it would seem when I hit group reply, for some reason, Evolution is putting Peter Stuge into the CC, and not Tom Wijsman (despite hitting group reply from your email. Maybe there should have been more testing of Gnome 3.8 before it was stabled on x86...
Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy
On Thu, 23 Jan 2014 18:04:19 -0600 Steev Klimaszewski st...@gentoo.org wrote: Your suggestion was expanding the arm keyword to armv4-linux, armv5-linux, armv6-linux, armv6-hardfloat-linux, armv7-softfp-linux, armv7-hardfloat-linux, armv7-hardfloat-uclibc-linux - that is nowhere near a good solution. We've ran over the reasons and they have appeared as fit for this idea. It can be prejudged as nowhere near a good solution; but for it to actually be that, it would need solid reasoning that people agree on. Reasoning is also needed to be able to figure out which conditions are fit for another solution; that way, the other solutions could be shaped with the help of that feedback to make the other solutions better. The /dev/null comment was about wanting others to do the work and not contributing anything more than (imo) a stupid idea The idea moves work from one place to another, which yields the same amount of work; your work statement seems like another topic, which you are making basic assumptions on. Solutions to the stated actual problem are neglected, as more time for research and consideration is needed. To get on the topic of your work statement; consider that one can find 7 people whom each have one arm configuration much faster than one can find 1 person that has all of them. if you aren't willing to put in the work, don't expect others to. If you are unwilling to work towards solutions, don't expect others to. And yes, I see what you mean now re: my reply seeming off - it would seem when I hit group reply, for some reason, Evolution is putting Peter Stuge into the CC, and not Tom Wijsman (despite hitting group reply from your email. Maybe there should have been more testing of Gnome 3.8 before it was stabled on x86... http://www.unicom.com/pw/reply-to-harmful.html http://woozle.org/~neale/papers/reply-to-still-harmful.html -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy
On Fri, 2014-01-24 at 04:04 +0100, Tom Wijsman wrote: On Thu, 23 Jan 2014 18:04:19 -0600 Steev Klimaszewski st...@gentoo.org wrote: Your suggestion was expanding the arm keyword to armv4-linux, armv5-linux, armv6-linux, armv6-hardfloat-linux, armv7-softfp-linux, armv7-hardfloat-linux, armv7-hardfloat-uclibc-linux - that is nowhere near a good solution. We've ran over the reasons and they have appeared as fit for this idea. It can be prejudged as nowhere near a good solution; but for it to actually be that, it would need solid reasoning that people agree on. Reasoning is also needed to be able to figure out which conditions are fit for another solution; that way, the other solutions could be shaped with the help of that feedback to make the other solutions better. The /dev/null comment was about wanting others to do the work and not contributing anything more than (imo) a stupid idea The idea moves work from one place to another, which yields the same amount of work; your work statement seems like another topic, which you are making basic assumptions on. Solutions to the stated actual problem are neglected, as more time for research and consideration is needed. To get on the topic of your work statement; consider that one can find 7 people whom each have one arm configuration much faster than one can find 1 person that has all of them. The idea moves the work around, it doesn't lessen the workload at all. You can easily find 7 people who have an armv7, and even v6, since the rpi is quite popular. Getting them into the arch team and willing to run stable and actually test programs is a whole other story, which lead to you saying: People that have certain architectures can just add themselves, no extra work again. And that's a show stopper, just randomly adding yourself to an arch team and claiming you've tested it is a nonstarter. Considering if there IS an issue, we then have to track you down and figure out why/what is different in the configuration that it's failing for others. You being on the QA team even offering that up as an option makes it questionable as to why you're on the QA team. That should never even be thought of as an option. What you've thrown out as a possible solution is akin to taking a pile of peas on the plate and moving them around the plate so that the pile doesn't look so big. It doesn't change the amount of work, but you do need to look in more places for the work. Finding people with the hardware is the main issue, and I think I mentioned before, some people are simply unwilling to invest in slow hardware, so we have to rely on the people who DO have it. And if that means things take longer to stable, well, why is that an issue? Stable is supposed to be that - stable. if you aren't willing to put in the work, don't expect others to. If you are unwilling to work towards solutions, don't expect others to. And yes, I see what you mean now re: my reply seeming off - it would seem when I hit group reply, for some reason, Evolution is putting Peter Stuge into the CC, and not Tom Wijsman (despite hitting group reply from your email. Maybe there should have been more testing of Gnome 3.8 before it was stabled on x86... http://www.unicom.com/pw/reply-to-harmful.html http://woozle.org/~neale/papers/reply-to-still-harmful.html I don't care of reply to is considered harmful, I care that something that worked with the previous stable is suddenly not working with the new stable. It obviously shows that it wasn't tested properly, and yet was marked stable. So, as QA, shouldn't you be doing something about that, rather than pointing to some URLs on the web, telling me I'm in the wrong for using the option that is supposed to handle that properly in my stable software?
