Re: [gentoo-dev] rfc: calling all eclass phase functions by default
17.08.2014 01:54, William Hubbs пишет: All, there is an ongoing discussion about how we handle eclass phase functions by default [1]. Currently, EXPORT_FUNCTIONS is called in eclasses, and because of the way this works, the phase function that is exported last in the chain of inherited eclasses is the one that is called for a given phase, overriding the PMS default phase function. The initial proposal is to change this behaviour so that the PMS default phase functions call all matching phase functions from inherited eclasses in sequence. For example: - your ebuild inherits foo and bar and each of them have src_unpack functions. With this new behaviour, the default src_unpack would run foo_src_unpack, bar_src_unpack, then perform its own actions. I strongly oppose this change, because I feel it will make our entire tree very unpredictable at best. I realize this might eliminate boilerplating from our tree. Weighing that against the possible ramifications in this big of a change in automagic behaviour, I think the cost is much higher than the gain. I am also not very comfortable with our current state, because it has a lot of uncertainty in terms of how the eclass phase functions are called. My counter proposal to this is that we stop calling eclass phase functions automatically, and to minimize the amount of boilerplating we would have to do, we use a variable, such as ECLASS_PHASES which would be defined at the ebuild level and contain a list of the eclass phase functions we want to run automatically. Going back to my previous example, say your ebuild does the following: -- code begins here -- inherit foo bar # Foo and bar both have src_unpack and src_install functions. # we want foo's src_unpack and bar's src_install: ECLASS_PHASES=foo_src_unpack bar_src_install -- code ends here --- If ECLASS_PHASES is undefined, I think the default should be to not run the eclass phase functions. Yes, this means there is some boilerplating. However, there are some strong advantages: - this is no longer dependent on order of inheritance. - The ebuild author knows exactly which eclass phase functions will be run. Thoughts? William [1] https://bugs.gentoo.org/show_bugs.cgi?id=516014 You have my strong opposition on such change as well. It will turn ebuilds into unreadable and undpredictable mess, please do not do that -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2014-08-10 23h59 UTC
12.08.2014 16:44, Jason Zaman пишет: On Tue, Aug 12, 2014 at 11:55:51AM +0400, Sergey Popov wrote: 11.08.2014 04:25, Robin H. Johnson пишет: The attached list notes all of the packages that were added or removed from the tree, for the week ending 2014-08-10 23h59 UTC. Removals: dev-vcs/gitosis 2014-08-04 04:35:46 robbat2 dev-vcs/gitosis-gentoo 2014-08-04 04:35:46 robbat2 What's about sec-policy/selinux-gitosis ? Should it be removed too? No, the selinux-gitosis policy has labels for gitolite too. It could perhaps be renamed eventually but not removed. -- Jason Ah, thanks, did not know about that. Then, of course, it can stay. -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: calling all eclass phase functions by default
On Mon, Aug 18, 2014 at 4:54 AM, Sergey Popov pinkb...@gentoo.org wrote: 17.08.2014 01:54, William Hubbs пишет: # Foo and bar both have src_unpack and src_install functions. # we want foo's src_unpack and bar's src_install: ECLASS_PHASES=foo_src_unpack bar_src_install You have my strong opposition on such change as well. It will turn ebuilds into unreadable and undpredictable mess, please do not do that I'm not sure I follow your complaint. He is talking about adding one line to an ebuild. I'm not sure how that is unreadable, and the algorithm you quoted looks fairly predictable to me as well. Certainly it is less convenient than not having to do anything to pull in eclass-defined phase functions, and it requires ebuilds to be updated when eclasses are updated to add new phase functions. That could be problematic for cases like KDE/X11/etc where you have a large collection of short ebuilds with all the logic in an eclass. I just want to make sure I'm understanding your concern in case there is a new issue being raised. Rich
Re: [gentoo-dev] rfc: calling all eclass phase functions by default
Sergey Popov: You have my strong opposition on such change as well. It will turn ebuilds into unreadable and undpredictable mess, please do not do that They are already fairly unreadable and unpredictable.
Re: [gentoo-dev] rfc: eclass issues
William Hubbs:
All,
I spoke with mgorny on IRC and found out what his concerns are about our
current eclasses.
First, he thinks we should get rid of base.eclass.
I know there is work going on to get rid of it, but I haven't really
looked into the status much yet. I do agree though, we shouldn't have a
general-purpose eclass like this that overrides default phase functions.
Things like this belong in PMS; not in an eclass.
The other concern he mentioned was indirectly inherited eclasses being
able to override phase functions.
He said for example that if an ebuild inherits foo and foo inherits bar,
foo should export all of the phase functions bar exports.
This may cause some boilerplating in some of the eclasses, so I'm
wondering if it would be feasible to make EXPORT_FUNCTIONS work only for
the first level of inheritance?
Thoughts?
I think the first thing to do and which already happened with e.g.
qmake-utils.eclass is to make a very strong distinction between utility
eclasses and those that export phase functions.
And yeah, disabling indirect exports would at worst cause some minor
boilerplating in eclasses (as in... you have to actually call
foo_src_compile() { base_src_compile ; } AND export it) instead of
ebuilds. That's reasonable IMO and makes them more readable and predictable.
In addition, we should probably fix the manpage format of the eclasses
with an explicit section about exported functions, so you don't have to
search for that info manually.
Re: [gentoo-dev] rfc: calling all eclass phase functions by default
18.08.2014 16:04, hasufell пишет: You have my strong opposition on such change as well. It will turn ebuilds into unreadable and undpredictable mess, please do not do that They are already fairly unreadable and unpredictable. For you - maybe. But not for me. I am NOT talking about hacks like putting additional *.as files through echo(hello Boost ebuild) or doing something crazy with subshells. But most of the eclass and ebuilds are readable quite simple if you read devmanual, PMS and have a brain. Of course, there are sometimes non-trivial stuff that is hard to read. But majority of ebuilds and eclasses are fine to understand and predict. So, without examples from you, this discussion will lead to nowhere, so, please let's stop it. -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: calling all eclass phase functions by default
18.08.2014 14:44, Rich Freeman пишет: On Mon, Aug 18, 2014 at 4:54 AM, Sergey Popov pinkb...@gentoo.org wrote: 17.08.2014 01:54, William Hubbs пишет: # Foo and bar both have src_unpack and src_install functions. # we want foo's src_unpack and bar's src_install: ECLASS_PHASES=foo_src_unpack bar_src_install You have my strong opposition on such change as well. It will turn ebuilds into unreadable and undpredictable mess, please do not do that I'm not sure I follow your complaint. He is talking about adding one line to an ebuild. I'm not sure how that is unreadable, and the algorithm you quoted looks fairly predictable to me as well. Certainly it is less convenient than not having to do anything to pull in eclass-defined phase functions, and it requires ebuilds to be updated when eclasses are updated to add new phase functions. That could be problematic for cases like KDE/X11/etc where you have a large collection of short ebuilds with all the logic in an eclass. I just want to make sure I'm understanding your concern in case there is a new issue being raised. What's bad with overriding needed functions and saying which exported functions(from eclasses) to execute and in which order? Is this approach flaw? In which ways? -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: calling all eclass phase functions by default
Sergey Popov: 18.08.2014 16:04, hasufell пишет: You have my strong opposition on such change as well. It will turn ebuilds into unreadable and undpredictable mess, please do not do that They are already fairly unreadable and unpredictable. For you - maybe. But not for me. I am NOT talking about hacks like putting additional *.as files through echo(hello Boost ebuild) or doing something crazy with subshells. But most of the eclass and ebuilds are readable quite simple if you read devmanual, PMS and have a brain. Of course, there are sometimes non-trivial stuff that is hard to read. But majority of ebuilds and eclasses are fine to understand and predict. So, without examples from you, this discussion will lead to nowhere, so, please let's stop it. From my time as a sunrise dev I strongly disagree. People have problems with understanding the mess, including actual programmers. They have enough technical understanding, but not the time or motivation to go through all those funny pitfalls which are NOT properly documented in devmanual. The most popular example is what we are talking about right now: indirect inheritance for example via games.eclass which inherits base.eclass but does not export src_unpack so stuff like unpacker.eclass and git-2.eclass will likely just do nothing if you inherit them before games.eclass (which is required by games herd policy)... uhm. I doubt you would have guessed this one if you saw the plain ebuild. I know the pitfall, so I see it just from looking at the inherit line. But it is far from being obvious.
Re: [gentoo-dev] rfc: calling all eclass phase functions by default
hasufell: Sergey Popov: 18.08.2014 16:04, hasufell пишет: You have my strong opposition on such change as well. It will turn ebuilds into unreadable and undpredictable mess, please do not do that They are already fairly unreadable and unpredictable. For you - maybe. But not for me. I am NOT talking about hacks like putting additional *.as files through echo(hello Boost ebuild) or doing something crazy with subshells. But most of the eclass and ebuilds are readable quite simple if you read devmanual, PMS and have a brain. Of course, there are sometimes non-trivial stuff that is hard to read. But majority of ebuilds and eclasses are fine to understand and predict. So, without examples from you, this discussion will lead to nowhere, so, please let's stop it. From my time as a sunrise dev I strongly disagree. People have problems with understanding the mess, including actual programmers. They have enough technical understanding, but not the time or motivation to go through all those funny pitfalls which are NOT properly documented in devmanual. The most popular example is what we are talking about right now: indirect inheritance for example via games.eclass which inherits base.eclass but does not export src_unpack so stuff like unpacker.eclass and git-2.eclass will likely just do nothing if you inherit them before games.eclass (which is required by games herd policy)... uhm. I doubt you would have guessed this one if you saw the plain ebuild. I know the pitfall, so I see it just from looking at the inherit line. But it is far from being obvious. Even more interesting... you can work around this by inheriting base.eclass explicitly before e.g. unpacker.eclass, something like inherit base unpacker games = unpacker_src_unpack() is carried out by default (and the ebuild breaks if someone thinks the base.eclass is useless and removes it) inherit unpacker games = unpacker_src_unpack is not carried out by default although games.eclass does not directly overwrite it If you think any of this is sensible...
Re: [gentoo-dev] rfc: calling all eclass phase functions by default
Dnia 2014-08-18, o godz. 12:41:11 hasufell hasuf...@gentoo.org napisał(a): hasufell: Sergey Popov: 18.08.2014 16:04, hasufell пишет: You have my strong opposition on such change as well. It will turn ebuilds into unreadable and undpredictable mess, please do not do that They are already fairly unreadable and unpredictable. For you - maybe. But not for me. I am NOT talking about hacks like putting additional *.as files through echo(hello Boost ebuild) or doing something crazy with subshells. But most of the eclass and ebuilds are readable quite simple if you read devmanual, PMS and have a brain. Of course, there are sometimes non-trivial stuff that is hard to read. But majority of ebuilds and eclasses are fine to understand and predict. So, without examples from you, this discussion will lead to nowhere, so, please let's stop it. From my time as a sunrise dev I strongly disagree. People have problems with understanding the mess, including actual programmers. They have enough technical understanding, but not the time or motivation to go through all those funny pitfalls which are NOT properly documented in devmanual. The most popular example is what we are talking about right now: indirect inheritance for example via games.eclass which inherits base.eclass but does not export src_unpack so stuff like unpacker.eclass and git-2.eclass will likely just do nothing if you inherit them before games.eclass (which is required by games herd policy)... uhm. I doubt you would have guessed this one if you saw the plain ebuild. I know the pitfall, so I see it just from looking at the inherit line. But it is far from being obvious. Even more interesting... you can work around this by inheriting base.eclass explicitly before e.g. unpacker.eclass, something like inherit base unpacker games This is a bug with vapier's approach at spanking and will be fixed. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: calling all eclass phase functions by default
hasufell: Even more interesting... you can work around this by inheriting base.eclass explicitly before e.g. unpacker.eclass, something like inherit base unpacker games = unpacker_src_unpack() is carried out by default (and the ebuild breaks if someone thinks the base.eclass is useless and removes it) inherit unpacker games = unpacker_src_unpack is not carried out by default although games.eclass does not directly overwrite it If you think any of this is sensible... Almost forgot, of course this does not work if you expect unpacker_src_unpacker() to run: inherit unpacker games base as well as inherit unpacker base games however inherit games unpacker base will work. And now... guess why the games herd made it a policy to always inherit games.eclass last. Because of the unpredictability of eclasses and that they may randomly add exported phase functions. It's a bit paranoid, but understandable, since we don't have any real rules here. So in the end 3 eclasses all tell you inherit me last! really!. Good luck with figuring out how to make a gnome game with python and multilib support work together. I can predict the days such a review would take in #gentoo-sunrise. Not less than 3.
Re: [gentoo-dev] rfc: eclass issues
On Mon, Aug 18, 2014 at 8:12 AM, hasufell hasuf...@gentoo.org wrote: I think the first thing to do and which already happened with e.g. qmake-utils.eclass is to make a very strong distinction between utility eclasses and those that export phase functions. Discussion on IRC the other day was moving in this direction as well. My email was almost contemplating a technical way of doing this, but I'm not entirely convinced that we could ever make a clean distinction between these. Certainly preventing automatic multiple inheritance would help though. I think that we should take a utility-vs-wraparound approach to eclass design. Each eclass should fall into one of the two categories and follow the principles for that category. I'm defining wraparound as shorthand for eclasses that export phase functions because often these eclasses do all the heavy lifting, with the ebuild just being a wrapper. Utility eclasses are pretty well-understood. They generally shouldn't export phase functions, and they can be used by a broad assortment of ebuilds (anything that uses an scm, a language, init helpers, manpage helpers, doc helpers, etc). They should export functions that do one thing well, and which stay out of the way unless called on. Wraparound eclasses are designed more for cases where ebuilds just declare variables and minimize their functionality by relying on inherited phase functions - the ebuild might not even implement any phase functions. For example, KDE ebuilds all share a lot of common logic from the eclass and just tell it which package they are building. They mostly share the same upstream, and they mostly share the same maintainers. This maximizes the upsides and minimizes the downsides of heavily automated eclasses. We get into trouble when we use wraparound eclasses: 1. With a broad assortment of ebuilds. 2. With many individual ebuild maintainers. 3. For things like languages or genres. 4. In situations where multiple wraparound eclasses could apply. I think in an ideal world we'd only have pure utility and wraparound eclasses. Utility eclasses would be used by procedural ebuilds where the execution flow is in the ebuild and it calls down to the eclass. Wraparound eclasses would be used by declarative ebuilds where the execution flow is in the eclass, and the ebuild just provides information that directs this flow. I think that is potentially a more powerful model, but only to the extent that you can write a single eclass that can handle a broad set of build/install systems/needs. So, for tomorrow I'm leaning towards: 1. Let's not ditch the status quo just yet. 2. Let's not expand eclass phase function logic any further. 3. Let's have some real discussion around what the actual problems are, and whether we can start moving towards tagging all our existing eclasses as utility vs wraparound. Oh, and I think the term wraparound sucks, so if somebody has a better one please toss it out there... -- Rich
Re: [gentoo-dev] rfc: calling all eclass phase functions by default
On 8/18/2014 8:56 AM, hasufell wrote: hasufell: Even more interesting... you can work around this by inheriting base.eclass explicitly before e.g. unpacker.eclass, something like inherit base unpacker games = unpacker_src_unpack() is carried out by default (and the ebuild breaks if someone thinks the base.eclass is useless and removes it) inherit unpacker games = unpacker_src_unpack is not carried out by default although games.eclass does not directly overwrite it If you think any of this is sensible... Almost forgot, of course this does not work if you expect unpacker_src_unpacker() to run: inherit unpacker games base as well as inherit unpacker base games however inherit games unpacker base will work. And now... guess why the games herd made it a policy to always inherit games.eclass last. Because of the unpredictability of eclasses and that they may randomly add exported phase functions. It's a bit paranoid, but understandable, since we don't have any real rules here. So in the end 3 eclasses all tell you inherit me last! really!. Good luck with figuring out how to make a gnome game with python and multilib support work together. I can predict the days such a review would take in #gentoo-sunrise. Not less than 3. Would it be feasible to add a repoman check for situations like this, where the behavior of a phase is dependent on inherit order? If so, it seems reasonable to me to require explicit calls to eclass functions in these cases to make it clear what's being called when. Chris Reffett
Re: [gentoo-dev] rfc: calling all eclass phase functions by default
On Mon, Aug 18, 2014 at 8:21 AM, Sergey Popov pinkb...@gentoo.org wrote: 18.08.2014 14:44, Rich Freeman пишет: On Mon, Aug 18, 2014 at 4:54 AM, Sergey Popov pinkb...@gentoo.org wrote: 17.08.2014 01:54, William Hubbs пишет: # Foo and bar both have src_unpack and src_install functions. # we want foo's src_unpack and bar's src_install: ECLASS_PHASES=foo_src_unpack bar_src_install You have my strong opposition on such change as well. It will turn ebuilds into unreadable and undpredictable mess, please do not do that I'm not sure I follow your complaint. He is talking about adding one line to an ebuild. I'm not sure how that is unreadable, and the algorithm you quoted looks fairly predictable to me as well. Certainly it is less convenient than not having to do anything to pull in eclass-defined phase functions, and it requires ebuilds to be updated when eclasses are updated to add new phase functions. That could be problematic for cases like KDE/X11/etc where you have a large collection of short ebuilds with all the logic in an eclass. I just want to make sure I'm understanding your concern in case there is a new issue being raised. What's bad with overriding needed functions and saying which exported functions(from eclasses) to execute and in which order? Is this approach flaw? In which ways? Ok, I was misunderstanding your original comment. You're advocating just having ebuilds explicitly call phase functions from eclasses then, and not automatically inheriting them? Your objection was to the ECLASS_PHASES concept, and not to the principle of eliminating automatic inheritance of phase functions? Please let me know if I'm still misunderstanding you. There are a lot of potential ways to go with this so it isn't always clear what part of a proposal is being objected to. Rich
Re: [gentoo-dev] rfc: calling all eclass phase functions by default
Chris Reffett: On 8/18/2014 8:56 AM, hasufell wrote: hasufell: Even more interesting... you can work around this by inheriting base.eclass explicitly before e.g. unpacker.eclass, something like inherit base unpacker games = unpacker_src_unpack() is carried out by default (and the ebuild breaks if someone thinks the base.eclass is useless and removes it) inherit unpacker games = unpacker_src_unpack is not carried out by default although games.eclass does not directly overwrite it If you think any of this is sensible... Almost forgot, of course this does not work if you expect unpacker_src_unpacker() to run: inherit unpacker games base as well as inherit unpacker base games however inherit games unpacker base will work. And now... guess why the games herd made it a policy to always inherit games.eclass last. Because of the unpredictability of eclasses and that they may randomly add exported phase functions. It's a bit paranoid, but understandable, since we don't have any real rules here. So in the end 3 eclasses all tell you inherit me last! really!. Good luck with figuring out how to make a gnome game with python and multilib support work together. I can predict the days such a review would take in #gentoo-sunrise. Not less than 3. Would it be feasible to add a repoman check for situations like this, where the behavior of a phase is dependent on inherit order? If so, it seems reasonable to me to require explicit calls to eclass functions in these cases to make it clear what's being called when. It would be feasible to turn off this implicit behavior. Adding repoman checks for these kind of things will just yell out the pitfalls instead of actually fixing them. People will still have to read through all the eclasses in order to know what to do. We need something you can rely on. EXPORT_FUNCTIONS line in the ebuild is currently not reliable, because we allow indirect exports. So we are back to the last proposal of williamh.
Re: [gentoo-dev] gentoo-x86 tree cleanup for 'DESCRIPTION ends with a '.' character' warnings
On 13 August 2014 02:46, Michał Górny mgo...@gentoo.org wrote: Dnia 2014-08-11, o godz. 20:48:20 William Hubbs willi...@gentoo.org napisał(a): got a minor (but chatty) QA warning: DESCRIPTION ends with a '.' character Why is this a QA warning in the first place? Because it is a common mistake, and having the warning in-place should help people avoid repeating it. This is correct. I don't recall a policy mandating that descriptions can't end with '.'. I asked our QA lead about it and was told that he didn't recall that we have an official policy about it either. Also, the devmanual never mentions any such requirement. I don't know if and where it is documented but that's what I was taught when I started contributing to Gentoo, and it pretty much follows the common sense. DESCRIPTION is supposed to be short and descriptive. So you do an elliptical sentence (if I got the right translation), and that doesn't end with a dot. Again, this is what I was taught as well. It may have been an undocumented rule, but it has been around for as long as I can remember. It also makes linguistic sense, and as an English teacher it always irks me when I see this mistake. If you have any fair reason to not follow this, please speak of it. Otherwise, this is pure bikeshed and waste of time. This thread already took much more time than fixing your packages if repoman complained about them. Amen! If someone can point me to something I'm missing, let me know. Otherwise, I think the warning should be removed. Even if there were no written-down policy, why would it be removed? What is the benefit of removing the check that resulted in many fixes already? Do you want to revert the removals afterwards? Or do you want to introduce new packages which use '.' there? I completely support this argument. The warning is correct and should remain in place. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] rfc: calling all eclass phase functions by default
Dnia 2014-08-18, o godz. 09:22:46 Chris Reffett creff...@gentoo.org napisał(a): On 8/18/2014 8:56 AM, hasufell wrote: Almost forgot, of course this does not work if you expect unpacker_src_unpacker() to run: inherit unpacker games base as well as inherit unpacker base games however inherit games unpacker base will work. And now... guess why the games herd made it a policy to always inherit games.eclass last. Because of the unpredictability of eclasses and that they may randomly add exported phase functions. It's a bit paranoid, but understandable, since we don't have any real rules here. So in the end 3 eclasses all tell you inherit me last! really!. Good luck with figuring out how to make a gnome game with python and multilib support work together. I can predict the days such a review would take in #gentoo-sunrise. Not less than 3. Would it be feasible to add a repoman check for situations like this, where the behavior of a phase is dependent on inherit order? If so, it seems reasonable to me to require explicit calls to eclass functions in these cases to make it clear what's being called when. Right now, we have no kind of repoman for eclasses. If you have time to work on such a thing, please do. Otherwise, all we can do is put more checks in ebuilds but that triggers the warning for the wrong people... -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: calling all eclass phase functions by default
On August 18, 2014 11:11:56 AM EDT, Michał Górny mgo...@gentoo.org wrote: Dnia 2014-08-18, o godz. 09:22:46 Chris Reffett creff...@gentoo.org napisał(a): On 8/18/2014 8:56 AM, hasufell wrote: Almost forgot, of course this does not work if you expect unpacker_src_unpacker() to run: inherit unpacker games base as well as inherit unpacker base games however inherit games unpacker base will work. And now... guess why the games herd made it a policy to always inherit games.eclass last. Because of the unpredictability of eclasses and that they may randomly add exported phase functions. It's a bit paranoid, but understandable, since we don't have any real rules here. So in the end 3 eclasses all tell you inherit me last! really!. Good luck with figuring out how to make a gnome game with python and multilib support work together. I can predict the days such a review would take in #gentoo-sunrise. Not less than 3. Would it be feasible to add a repoman check for situations like this, where the behavior of a phase is dependent on inherit order? If so, it seems reasonable to me to require explicit calls to eclass functions in these cases to make it clear what's being called when. Right now, we have no kind of repoman for eclasses. If you have time to work on such a thing, please do. Otherwise, all we can do is put more checks in ebuilds but that triggers the warning for the wrong people... I was thinking more ebuild-side. Example: my ebuild inherits both cmake-utils and games eclasses, and I don't explicitly define src_compile, repoman full could pop up a warning like src_compile is ambiguous between cmake-utils_src_compile and games_src_compile, please explicitly define this phase and call the appropriate eclass function. I imagine that this would pop up a lot of warnings, but I feel like it would improve readability and make it explicit what should be going on where. I concede that it could make a lot more boilerplate code in ebuilds, so that's a potential issue, mostly just throwing out an idea here. Chris Reffett
Re: [gentoo-dev] rfc: calling all eclass phase functions by default
Dnia 2014-08-18, o godz. 15:37:26 Chris Reffett creff...@gentoo.org napisał(a): On August 18, 2014 11:11:56 AM EDT, Michał Górny mgo...@gentoo.org wrote: Dnia 2014-08-18, o godz. 09:22:46 Chris Reffett creff...@gentoo.org napisał(a): On 8/18/2014 8:56 AM, hasufell wrote: Almost forgot, of course this does not work if you expect unpacker_src_unpacker() to run: inherit unpacker games base as well as inherit unpacker base games however inherit games unpacker base will work. And now... guess why the games herd made it a policy to always inherit games.eclass last. Because of the unpredictability of eclasses and that they may randomly add exported phase functions. It's a bit paranoid, but understandable, since we don't have any real rules here. So in the end 3 eclasses all tell you inherit me last! really!. Good luck with figuring out how to make a gnome game with python and multilib support work together. I can predict the days such a review would take in #gentoo-sunrise. Not less than 3. Would it be feasible to add a repoman check for situations like this, where the behavior of a phase is dependent on inherit order? If so, it seems reasonable to me to require explicit calls to eclass functions in these cases to make it clear what's being called when. Right now, we have no kind of repoman for eclasses. If you have time to work on such a thing, please do. Otherwise, all we can do is put more checks in ebuilds but that triggers the warning for the wrong people... I was thinking more ebuild-side. Example: my ebuild inherits both cmake-utils and games eclasses, and I don't explicitly define src_compile, repoman full could pop up a warning like src_compile is ambiguous between cmake-utils_src_compile and games_src_compile, please explicitly define this phase and call the appropriate eclass function. I imagine that this would pop up a lot of warnings, but I feel like it would improve readability and make it explicit what should be going on where. I concede that it could make a lot more boilerplate code in ebuilds, so that's a potential issue, mostly just throwing out an idea here. People will be unhappy about it. Well, I will be unhappy about it. Maybe if we had different eclasses... but with what we have now, I'd rather order eclasses properly than redefine each phase. Maybe we could agree on something lighter, say, that src_configure() through src_install() should come from the same eclass. Also, please wrap your mails. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: calling all eclass phase functions by default
Chris Reffett:
On August 18, 2014 11:11:56 AM EDT, Michał Górny mgo...@gentoo.org wrote:
Dnia 2014-08-18, o godz. 09:22:46
Chris Reffett creff...@gentoo.org napisał(a):
On 8/18/2014 8:56 AM, hasufell wrote:
Almost forgot, of course this does not work if you expect
unpacker_src_unpacker() to run:
inherit unpacker games base
as well as
inherit unpacker base games
however
inherit games unpacker base
will work.
And now... guess why the games herd made it a policy to always
inherit
games.eclass last. Because of the unpredictability of eclasses and
that
they may randomly add exported phase functions. It's a bit
paranoid, but
understandable, since we don't have any real rules here.
So in the end 3 eclasses all tell you inherit me last! really!.
Good
luck with figuring out how to make a gnome game with python and
multilib
support work together. I can predict the days such a review would
take
in #gentoo-sunrise. Not less than 3.
Would it be feasible to add a repoman check for situations like this,
where the behavior of a phase is dependent on inherit order? If so,
it
seems reasonable to me to require explicit calls to eclass functions
in
these cases to make it clear what's being called when.
Right now, we have no kind of repoman for eclasses. If you have time to
work on such a thing, please do. Otherwise, all we can do is put more
checks in ebuilds but that triggers the warning for the wrong people...
I was thinking more ebuild-side. Example: my ebuild inherits both cmake-utils
and games eclasses, and I don't explicitly define src_compile, repoman full
could pop up a warning like src_compile is ambiguous between
cmake-utils_src_compile and games_src_compile, please explicitly define this
phase and call the appropriate eclass function. I imagine that this would
pop up a lot of warnings, but I feel like it would improve readability and
make it explicit what should be going on where. I concede that it could make
a lot more boilerplate code in ebuilds, so that's a potential issue, mostly
just throwing out an idea here.
Chris Reffett
I don't want to code against warning tools, but against a reliable API.
That said, EXPORT_FUNCTIONS in eclasses should be definite and
non-recursive. Currently, people have to track down the actual exported
functions themselves through the endless list of indirect inheritance
which may:
* randomly change
* be highly dependant on the inherit order in the eclass and of those
indirectly inheriting others...
So to pick up the proposal again, I think this could make sense:
* disable exported functions from indirectly inherited eclasses
* have eclass authors do these things explicitly, so they have to export
ALL functions themselves and may have to adjust their eclasses, as in:
games_src_prepare() { base_src_prepare ; } (I know that base.eclass is
deprecated, this is an example)
* include the exported functions automatically in the generated eclass
manpages
[gentoo-dev] Initial (partial) EAPI6 implementation for Portage
Hello, Since most of EAPI6 seems to be defined already, I've started working on an initial implementation for Portage. Since many of the features are not precisely defined yet, I've made a few assumptions. I'd like to ask you to look through it and ask any questions that may arise or report any issues you see. As a note, I've implemented everything in the accepted list [1] except for runtime USE flags (sorry, Ciaran, not yet). I've also added --docdir and --htmldir [2] since I was requested to test it more. If possible, feel free to test it. The ebuilds need to be EAPI=6_pre1 for it. The code is available in 'eapi6' branch of my Portage mirror. To clone: $ git clone -b eapi6 https://github.com/mgorny/portage.git To install via portage-, put the following in make.conf: portage_LIVE_REPO=https://github.com/mgorny/portage.git portage_LIVE_BRANCH=eapi6 To view online (and feel free to comment via github): https://github.com/mgorny/portage/commits/eapi6 To compare the EAPI6 added content: https://github.com/mgorny/portage/compare/mgorny:random-cleanup...eapi6 Thanks and have fun! [1]:https://wiki.gentoo.org/wiki/Future_EAPI/EAPI_6_tentative_features [2]:https://bugs.gentoo.org/show_bug.cgi?id=468202 -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Followup notes: {cvs,git,git.overlays}.gentoo.org migration; awol: some overlays commits, gitweb
Hi all, Last evening, the old sponsor where cvs/git/git.overlays was hosted turned off the old servers, earlier than I expected. With two notable exceptions listed below, almost everything should be how it should be, so you can continue as before. The new SSH keys, in case you still didn't have them: On Mon, Jun 30, 2014 at 10:26:52PM +, Robin H. Johnson wrote: 1024 5f:c3:fe:9a:ac:a7:99:f4:d3:c1:93:4c:52:87:74:28 (DSA) 256 aa:6a:e4:74:1d:73:d2:5a:9f:45:9f:18:55:81:c9:9a (ECDSA) 256 1c:2e:99:7d:c7:f0:bc:3b:a9:fb:d0:3e:2c:2a:79:ba (ED25519) 2048 24:3b:2d:3b:47:ca:7e:62:48:97:49:6a:f5:ad:66:88 (RSA) 1. Overlays missing commits since 2014/07/22 02:49 UTC --- So last time overlays had an outage, infra promised to look into a git mirroring setup, so when this forced migration was announced, I started to implement a very rough version of mirroring for both the main cvs/git repos, as well as the overlays repos. It worked on the primary repos, but after some initial runs it failed on all of the git.overlays repos at Jul 22 02:49 UTC. I've been busy with real life, and I unfortunately didn't notice it until too late. As a direct result, any commits pushed to git.overlays repos after 2014/07/22 22 02:49 UTC, are missing. If you have them locally, all you need to do is 'git push' for all of your branches, and they'll be restored. 2. gitweb/cgit offline, anongit rate-limited - One of the plans was to merge the hosting of git.gentoo.org and git.overlays.gentoo.org into a single large Gitolite deployment, in preparation for the Git migration of gentoo-x86. The gotcha is that while we want all of the write traffic to be consolidated, we want to be able to scale the readonly capacity easily (without the budget or sharding that GitHub has). It isn't a 100% solved problem yet (one of the reasons that I hadn't flipped stuff over yet). There is also a lot more read-only Git traffic than I expected (enough to kill some systems); so I'm NOT enabling a web server on the box that runs the readwrite traffic yet. The leading solution I have, that allows the most flexibility, is simply splitting at the hostname: http://gitweb.gentoo.org/$REPO git://readonly.git.gentoo.org/$REPO git://ro.git.gentoo.org/$REPO git+ssh://g...@readwrite.git.gentoo.org/$REPO git+ssh://g...@rw.git.gentoo.org/$REPO This also lets us trivially distribute readonly mirrors distributed around the world, which would hugely improve performance when the Git migration is done. As a migration plan, git.gentoo.org would continue to host R+RW git for a month. Any concerns or alternative ideas should be proposed on the gentoo-dev lists. -- Robin Hugh Johnson Gentoo Linux: Developer, Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
[gentoo-portage-dev] [PATCH] Apply 'nonfatal' to helpers only
Make 'nonfatal' modifier affect helpers only rather than disabling 'die'
completely. This improves the PMS conformance.
---
bin/isolated-functions.sh | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/bin/isolated-functions.sh b/bin/isolated-functions.sh
index a22af57..d41f0b3 100644
--- a/bin/isolated-functions.sh
+++ b/bin/isolated-functions.sh
@@ -106,7 +106,7 @@ __bashpid() {
}
__helpers_die() {
- if ___eapi_helpers_can_die; then
+ if ___eapi_helpers_can_die [[ ${PORTAGE_NONFATAL} != 1 ]]; then
die $@
else
echo -e $@ 2
@@ -116,11 +116,6 @@ __helpers_die() {
die() {
local IFS=$' \t\n'
- if [[ $PORTAGE_NONFATAL -eq 1 ]]; then
- echo -e $WARN*$NORMAL ${FUNCNAME[1]}: WARNING: $@ 2
- return 1
- fi
-
set +e
if [ -n ${QA_INTERCEPTORS} ] ; then
# die was called from inside inherit. We need to clean up
--
2.0.4
Re: [gentoo-portage-dev] [PATCH] Apply 'nonfatal' to helpers only
2014-08-18 11:02 Michał Górny napisał(a): Make 'nonfatal' modifier affect helpers only rather than disabling 'die' completely. This improves the PMS conformance. It is better to leave current code, until there is replacement functionality. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] [PATCH] Apply 'nonfatal' to helpers only
Dnia 2014-08-18, o godz. 14:00:08 Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com napisał(a): 2014-08-18 11:02 Michał Górny napisał(a): Make 'nonfatal' modifier affect helpers only rather than disabling 'die' completely. This improves the PMS conformance. It is better to leave current code, until there is replacement functionality. The replacement functionality is in EAPI 6. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-portage-dev] [PATCH] Rewrite default ebuild phase setting code
Replace the ebuild phase setting code for EAPI 2 and newer with a
simpler approach; first set proper default_* functions, and call them
within the phase. Disallow calling default_* for other phase functions
than the one being run.
---
bin/phase-functions.sh | 117 ++---
bin/save-ebuild-env.sh | 2 +-
2 files changed, 53 insertions(+), 66 deletions(-)
diff --git a/bin/phase-functions.sh b/bin/phase-functions.sh
index f39a024..954f1a3 100644
--- a/bin/phase-functions.sh
+++ b/bin/phase-functions.sh
@@ -734,91 +734,78 @@ __ebuild_phase_funcs() {
[ $# -ne 2 ] die expected exactly 2 args, got $#: $*
local eapi=$1
local phase_func=$2
- local default_phases=pkg_nofetch src_unpack src_prepare src_configure
- src_compile src_install src_test
- local x y default_func=
-
- for x in pkg_nofetch src_unpack src_test ; do
- declare -F $x /dev/null || \
- eval $x() { __eapi0_$x \\$@\ ; }
+ local all_phases=src_compile pkg_config src_configure pkg_info
+ src_install pkg_nofetch pkg_postinst pkg_postrm pkg_preinst
+ src_prepare pkg_prerm pkg_pretend pkg_setup src_test src_unpack
+ local x
+
+ # First, set up the error handlers for default*
+ for x in ${all_phases} ; do
+ eval default_${x}() {
+ die \default_${x}() is not supported in EAPI='${eapi}'
in phase ${phase_func}\
+ }
done
+ # We can just call the specific handler -- it will either error out
+ # on invalid phase or run it.
+ eval default() {
+ default_${phase_func}
+ }
+
case $eapi in
+ 0|1) # EAPIs not supporting 'default'
- 0|1)
+ for x in pkg_nofetch src_unpack src_test ; do
+ declare -F $x /dev/null || \
+ eval $x() { __eapi0_$x; }
+ done
if ! declare -F src_compile /dev/null ; then
case $eapi in
0)
- src_compile() {
__eapi0_src_compile $@ ; }
+ src_compile() {
__eapi0_src_compile; }
;;
*)
- src_compile() {
__eapi1_src_compile $@ ; }
+ src_compile() {
__eapi1_src_compile; }
;;
esac
fi
-
- for x in $default_phases ; do
- eval default_$x() {
- die \default_$x() is not supported
with EAPI='$eapi' during phase $phase_func\
- }
- done
-
- eval default() {
- die \default() is not supported with
EAPI='$eapi' during phase $phase_func\
- }
-
;;
- *)
-
+ *) # EAPIs supporting 'default'
+
+ # defaults starting with EAPI 0
+ [[ ${phase_func} == pkg_nofetch ]] \
+ default_pkg_nofetch() { __eapi0_pkg_nofetch; }
+ [[ ${phase_func} == src_unpack ]] \
+ default_src_unpack() { __eapi0_src_unpack; }
+ [[ ${phase_func} == src_test ]] \
+ default_src_test() { __eapi0_src_test; }
+
+ # defaults starting with EAPI 2
+ [[ ${phase_func} == src_configure ]] \
+ default_src_configure() {
__eapi2_src_configure; }
+ [[ ${phase_func} == src_compile ]] \
+ default_src_compile() { __eapi2_src_compile; }
+
+ # bind supported phases to the defaults
+ declare -F src_unpack /dev/null || \
+ src_unpack() { default; }
declare -F src_configure /dev/null || \
- src_configure() { __eapi2_src_configure $@ ; }
-
+ src_configure() { default; }
declare -F src_compile /dev/null || \
- src_compile() { __eapi2_src_compile $@ ; }
-
- has $eapi 2 3 || declare -F src_install /dev/null || \
- src_install() { __eapi4_src_install $@ ; }
+ src_compile() { default; }
+ declare -F src_test /dev/null || \
+
Re: [gentoo-portage-dev] [PATCH] Apply 'nonfatal' to helpers only
On Mon, 18 Aug 2014 14:04:32 +0200 Michał Górny mgo...@gentoo.org wrote: Dnia 2014-08-18, o godz. 14:00:08 Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com napisał(a): 2014-08-18 11:02 Michał Górny napisał(a): Make 'nonfatal' modifier affect helpers only rather than disabling 'die' completely. This improves the PMS conformance. It is better to leave current code, until there is replacement functionality. The replacement functionality is in EAPI 6. Then perhaps your commit message should have stated this is an EAPI 6 involved change. Also, EAPI 6 is no where near started to be supported in portage. So if this is an EAPI 6 change, it is the first. -- Brian Dolbec dolsen signature.asc Description: PGP signature
[gentoo-portage-dev] [PATCH 4/6] Make eapi_is_supported() reuse _supported_eapis list
Make the eapi_is_supported() function use the generated list of supported EAPIs rather than partial lists and integer comparison. --- pym/portage/__init__.py | 14 +- 1 file changed, 1 insertion(+), 13 deletions(-) diff --git a/pym/portage/__init__.py b/pym/portage/__init__.py index 18b2599..66bfeb0 100644 --- a/pym/portage/__init__.py +++ b/pym/portage/__init__.py @@ -505,19 +505,7 @@ def eapi_is_supported(eapi): eapi = str(eapi) eapi = eapi.strip() - if _eapi_is_deprecated(eapi): - return True - - if eapi in _testing_eapis: - return True - - try: - eapi = int(eapi) - except ValueError: - eapi = -1 - if eapi 0: - return False - return eapi = portage.const.EAPI + return eapi in _supported_eapis # This pattern is specified by PMS section 7.3.1. _pms_eapi_re = re.compile(r^[ \t]*EAPI=(['\]?)([A-Za-z0-9+_.-]*)\1[ \t]*([ \t]#.*)?$) -- 2.0.4
[gentoo-portage-dev] [PATCH 5/6] Apply 'nonfatal' to helpers only
Make 'nonfatal' modifier affect helpers only rather than disabling 'die'
completely. This improves the PMS conformance.
---
bin/isolated-functions.sh | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/bin/isolated-functions.sh b/bin/isolated-functions.sh
index a22af57..d41f0b3 100644
--- a/bin/isolated-functions.sh
+++ b/bin/isolated-functions.sh
@@ -106,7 +106,7 @@ __bashpid() {
}
__helpers_die() {
- if ___eapi_helpers_can_die; then
+ if ___eapi_helpers_can_die [[ ${PORTAGE_NONFATAL} != 1 ]]; then
die $@
else
echo -e $@ 2
@@ -116,11 +116,6 @@ __helpers_die() {
die() {
local IFS=$' \t\n'
- if [[ $PORTAGE_NONFATAL -eq 1 ]]; then
- echo -e $WARN*$NORMAL ${FUNCNAME[1]}: WARNING: $@ 2
- return 1
- fi
-
set +e
if [ -n ${QA_INTERCEPTORS} ] ; then
# die was called from inside inherit. We need to clean up
--
2.0.4
[gentoo-portage-dev] [PATCH 1/6] econf: Replace unnecessary 'case' statements with 'if's
Replace the 'case' statements used to match 'configure' output with
simpler pattern-matching 'if's.
Acked-by: Alexander Berntsen berna...@gentoo.org
---
bin/phase-helpers.sh | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/bin/phase-helpers.sh b/bin/phase-helpers.sh
index 47bd843..6a5ce85 100644
--- a/bin/phase-helpers.sh
+++ b/bin/phase-helpers.sh
@@ -525,19 +525,15 @@ econf() {
local conf_help=$(${ECONF_SOURCE}/configure --help
2/dev/null)
if ___eapi_econf_passes_--disable-dependency-tracking;
then
- case ${conf_help} in
- *--disable-dependency-tracking*)
- set --
--disable-dependency-tracking $@
- ;;
- esac
+ if [[ ${conf_help} ==
*--disable-dependency-tracking* ]]; then
+ set -- --disable-dependency-tracking
$@
+ fi
fi
if ___eapi_econf_passes_--disable-silent-rules; then
- case ${conf_help} in
- *--disable-silent-rules*)
- set -- --disable-silent-rules
$@
- ;;
- esac
+ if [[ ${conf_help} == *--disable-silent-rules*
]]; then
+ set -- --disable-silent-rules $@
+ fi
fi
fi
--
2.0.4
[gentoo-portage-dev] [PATCHES] Random issues and refactoring before EAPI6 series
dol-sen asked me to send all of them in a serie. Those are minor bugfixes and code refactoring done to prepare for EAPI6 code. 1 2 cleans up econf. In EAPI6 we will likely be adding --docdir and --htmldir there, so we should add it in nice code rather than copying the bad one. 3-4 aim to clean up EAPI handling a bit. It's far from perfect, but 3 at least fixes the bug that EAPI 5 is considered unsupported. Further changes can be done in the future. 5 fixes PMS incompatibility that causes 'nonfatal' to prevent 'die' from working correctly. I'm pretty sure the bug was mentioned by PMS team already but nobody considered it important enough to report a bug. EAPI 6 'nonfatal die' support will land in place of that conditional. 6 aims to simplify the phase setting function that is hard to understand and the moment, and has a few unnecessary, hard-to-understand side effects like declaring non-existent __eapi2_src_*() phases. The new code is much cleaner and makes adding new phases in future EAPIs trivial. It also prevents from calling default_* function for another phase as forbidden by PMS. -- Michał Górny
[gentoo-portage-dev] [PATCH 6/6] Rewrite default ebuild phase setting code
Replace the ebuild phase setting code for EAPI 2 and newer with a
simpler approach; first set proper default_* functions, and call them
within the phase. Disallow calling default_* for other phase functions
than the one being run.
---
bin/phase-functions.sh | 117 ++---
bin/save-ebuild-env.sh | 2 +-
2 files changed, 53 insertions(+), 66 deletions(-)
diff --git a/bin/phase-functions.sh b/bin/phase-functions.sh
index f39a024..b7fb5d7 100644
--- a/bin/phase-functions.sh
+++ b/bin/phase-functions.sh
@@ -734,91 +734,78 @@ __ebuild_phase_funcs() {
[ $# -ne 2 ] die expected exactly 2 args, got $#: $*
local eapi=$1
local phase_func=$2
- local default_phases=pkg_nofetch src_unpack src_prepare src_configure
- src_compile src_install src_test
- local x y default_func=
-
- for x in pkg_nofetch src_unpack src_test ; do
- declare -F $x /dev/null || \
- eval $x() { __eapi0_$x \\$@\ ; }
+ local all_phases=src_compile pkg_config src_configure pkg_info
+ src_install pkg_nofetch pkg_postinst pkg_postrm pkg_preinst
+ src_prepare pkg_prerm pkg_pretend pkg_setup src_test src_unpack
+ local x
+
+ # First, set up the error handlers for default*
+ for x in ${all_phases} ; do
+ eval default_${x}() {
+ die \default_${x}() is not supported in EAPI='${eapi}'
in phase ${phase_func}\
+ }
done
+ # We can just call the specific handler -- it will either error out
+ # on invalid phase or run it.
+ eval default() {
+ default_${phase_func}
+ }
+
case $eapi in
+ 0|1) # EAPIs not supporting 'default'
- 0|1)
+ for x in pkg_nofetch src_unpack src_test ; do
+ declare -F $x /dev/null || \
+ eval $x() { __eapi0_$x; }
+ done
if ! declare -F src_compile /dev/null ; then
case $eapi in
0)
- src_compile() {
__eapi0_src_compile $@ ; }
+ src_compile() {
__eapi0_src_compile; }
;;
*)
- src_compile() {
__eapi1_src_compile $@ ; }
+ src_compile() {
__eapi1_src_compile; }
;;
esac
fi
-
- for x in $default_phases ; do
- eval default_$x() {
- die \default_$x() is not supported
with EAPI='$eapi' during phase $phase_func\
- }
- done
-
- eval default() {
- die \default() is not supported with
EAPI='$eapi' during phase $phase_func\
- }
-
;;
- *)
-
+ *) # EAPIs supporting 'default'
+
+ # defaults starting with EAPI 0
+ [[ ${phase_func} == pkg_nofetch ]] \
+ default_pkg_nofetch() { __eapi0_pkg_nofetch; }
+ [[ ${phase_func} == src_unpack ]] \
+ default_src_unpack() { __eapi0_src_unpack; }
+ [[ ${phase_func} == src_test ]] \
+ default_src_test() { __eapi0_src_test; }
+
+ # defaults starting with EAPI 2
+ [[ ${phase_func} == src_configure ]] \
+ default_src_configure() {
__eapi2_src_configure; }
+ [[ ${phase_func} == src_compile ]] \
+ default_src_compile() { __eapi2_src_compile; }
+
+ # bind supported phases to the defaults
+ declare -F src_unpack /dev/null || \
+ src_unpack() { default; }
declare -F src_configure /dev/null || \
- src_configure() { __eapi2_src_configure $@ ; }
-
+ src_configure() { default; }
declare -F src_compile /dev/null || \
- src_compile() { __eapi2_src_compile $@ ; }
-
- has $eapi 2 3 || declare -F src_install /dev/null || \
- src_install() { __eapi4_src_install $@ ; }
+ src_compile() { default; }
+ declare -F src_test /dev/null || \
+
[gentoo-portage-dev] [PATCH 2/6] econf: Add EAPI-conditional arguments via array
Use a dedicated array variable to add EAPI-conditional arguments to
the configure script instead of prepending them to the command
parameters.
---
bin/phase-helpers.sh | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/bin/phase-helpers.sh b/bin/phase-helpers.sh
index 6a5ce85..b96c3f5 100644
--- a/bin/phase-helpers.sh
+++ b/bin/phase-helpers.sh
@@ -521,18 +521,19 @@ econf() {
done
fi
+ local conf_args=()
if ___eapi_econf_passes_--disable-dependency-tracking ||
___eapi_econf_passes_--disable-silent-rules; then
local conf_help=$(${ECONF_SOURCE}/configure --help
2/dev/null)
if ___eapi_econf_passes_--disable-dependency-tracking;
then
if [[ ${conf_help} ==
*--disable-dependency-tracking* ]]; then
- set -- --disable-dependency-tracking
$@
+ conf_args+=(
--disable-dependency-tracking )
fi
fi
if ___eapi_econf_passes_--disable-silent-rules; then
if [[ ${conf_help} == *--disable-silent-rules*
]]; then
- set -- --disable-silent-rules $@
+ conf_args+=( --disable-silent-rules )
fi
fi
fi
@@ -550,7 +551,9 @@ econf() {
CONF_PREFIX=${CONF_PREFIX#*=}
[[ ${CONF_PREFIX} != /* ]]
CONF_PREFIX=/${CONF_PREFIX}
[[ ${CONF_LIBDIR} != /* ]]
CONF_LIBDIR=/${CONF_LIBDIR}
- set -- --libdir=$(__strip_duplicate_slashes
${CONF_PREFIX}${CONF_LIBDIR}) $@
+ conf_args+=(
+ --libdir=$(__strip_duplicate_slashes
${CONF_PREFIX}${CONF_LIBDIR})
+ )
fi
# Handle arguments containing quoted whitespace (see bug
#457136).
@@ -566,6 +569,7 @@ econf() {
--datadir=${EPREFIX}/usr/share \
--sysconfdir=${EPREFIX}/etc \
--localstatedir=${EPREFIX}/var/lib \
+ ${conf_args[@]} \
$@ \
${EXTRA_ECONF[@]}
__vecho ${ECONF_SOURCE}/configure $@
--
2.0.4
[gentoo-portage-dev] [PATCH 01/13] Support EAPI=6_pre1 for testing EAPI6 features
--- pym/portage/__init__.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pym/portage/__init__.py b/pym/portage/__init__.py index 66bfeb0..0046161 100644 --- a/pym/portage/__init__.py +++ b/pym/portage/__init__.py @@ -491,7 +491,7 @@ def abssymlink(symlink, target=None): _doebuild_manifest_exempt_depend = 0 -_testing_eapis = frozenset([4-python, 4-slot-abi, 5-progress, 5-hdepend]) +_testing_eapis = frozenset([4-python, 4-slot-abi, 5-progress, 5-hdepend, 6_pre1]) _deprecated_eapis = frozenset([4_pre1, 3_pre2, 3_pre1, 5_pre1, 5_pre2]) _supported_eapis = frozenset([str(x) for x in range(portage.const.EAPI + 1)] + list(_testing_eapis) + list(_deprecated_eapis)) -- 2.0.4
[gentoo-portage-dev] [PATCH 03/13] Add tentative support for EAPI6 get_libdir()
Add get_libdir() function to obtain the basename of libdir using
the same algorithm that econf uses.
---
bin/eapi.sh | 4
bin/phase-helpers.sh | 11 +++
2 files changed, 15 insertions(+)
diff --git a/bin/eapi.sh b/bin/eapi.sh
index 5f96c3b..6ace20d 100644
--- a/bin/eapi.sh
+++ b/bin/eapi.sh
@@ -64,6 +64,10 @@ ___eapi_has_usex() {
[[ ! ${1-${EAPI}} =~ ^(0|1|2|3|4|4-python|4-slot-abi)$ ]]
}
+___eapi_has_get_libdir() {
+ [[ ! ${1-${EAPI}} =~
^(0|1|2|3|4|4-python|4-slot-abi|5|5-hdepend|5-progress)$ ]]
+}
+
___eapi_has_master_repositories() {
[[ ${1-${EAPI}} =~ ^(5-progress)$ ]]
}
diff --git a/bin/phase-helpers.sh b/bin/phase-helpers.sh
index c2161f6..8edbc07 100644
--- a/bin/phase-helpers.sh
+++ b/bin/phase-helpers.sh
@@ -842,6 +842,17 @@ best_version() {
esac
}
+if ___eapi_has_get_libdir; then
+ get_libdir() {
+ local libdir_var=LIBDIR_${ABI}
+ local libdir=lib
+
+ [[ -n ${ABI} -n ${!libdir_var} ]] libdir=${!libdir_var}
+
+ echo ${libdir}
+ }
+fi
+
if ___eapi_has_master_repositories; then
master_repositories() {
local output repository=$1 retval
--
2.0.4
[gentoo-portage-dev] [PATCH 02/13] Add tentative support for EAPI6 --docdir and --htmldir
Pass --docdir and --htmldir to configure scripts that support it.
---
bin/eapi.sh | 4
bin/phase-helpers.sh | 12 +++-
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/bin/eapi.sh b/bin/eapi.sh
index 623b89f..5f96c3b 100644
--- a/bin/eapi.sh
+++ b/bin/eapi.sh
@@ -110,6 +110,10 @@ ___eapi_econf_passes_--disable-silent-rules() {
[[ ! ${1-${EAPI}} =~ ^(0|1|2|3|4|4-python|4-slot-abi)$ ]]
}
+___eapi_econf_passes_--docdir_and_--htmldir() {
+ [[ ! ${1-${EAPI}} =~
^(0|1|2|3|4|4-python|4-slot-abi|5|5-hdepend|5-progress)$ ]]
+}
+
___eapi_use_enable_and_use_with_support_empty_third_argument() {
[[ ! ${1-${EAPI}} =~ ^(0|1|2|3)$ ]]
}
diff --git a/bin/phase-helpers.sh b/bin/phase-helpers.sh
index b96c3f5..c2161f6 100644
--- a/bin/phase-helpers.sh
+++ b/bin/phase-helpers.sh
@@ -522,7 +522,7 @@ econf() {
fi
local conf_args=()
- if ___eapi_econf_passes_--disable-dependency-tracking ||
___eapi_econf_passes_--disable-silent-rules; then
+ if ___eapi_econf_passes_--disable-dependency-tracking ||
___eapi_econf_passes_--disable-silent-rules ||
___eapi_econf_passes_--docdir_and_--htmldir; then
local conf_help=$(${ECONF_SOURCE}/configure --help
2/dev/null)
if ___eapi_econf_passes_--disable-dependency-tracking;
then
@@ -536,6 +536,16 @@ econf() {
conf_args+=( --disable-silent-rules )
fi
fi
+
+ if ___eapi_econf_passes_--docdir_and_--htmldir; then
+ if [[ ${conf_help} == *--docdir* ]]; then
+ conf_args+=(
--docdir=${EPREFIX}/usr/share/doc/${PF} )
+ fi
+
+ if [[ ${conf_help} == *--htmldir* ]]; then
+ conf_args+=(
--htmldir=${EPREFIX}/usr/share/doc/${PF}/html )
+ fi
+ fi
fi
# if the profile defines a location to install libs to aside
from default, pass it on.
--
2.0.4
[gentoo-portage-dev] [PATCH 09/13] Add tentative EAPI6 .txz unpack support
Support unpacking .txz-suffixed archives.
---
bin/eapi.sh | 4
bin/phase-helpers.sh | 13 +
2 files changed, 17 insertions(+)
diff --git a/bin/eapi.sh b/bin/eapi.sh
index fa57999..878f8e7 100644
--- a/bin/eapi.sh
+++ b/bin/eapi.sh
@@ -118,6 +118,10 @@ ___eapi_unpack_supports_xz() {
[[ ! ${1-${EAPI}} =~ ^(0|1|2)$ ]]
}
+___eapi_unpack_supports_txz() {
+ [[ ! ${1-${EAPI}} =~
^(0|1|2|3|4|4-python|4-slot-abi|5|5-hdepend|5-progress)$ ]]
+}
+
___eapi_econf_passes_--disable-dependency-tracking() {
[[ ! ${1-${EAPI}} =~ ^(0|1|2|3)$ ]]
}
diff --git a/bin/phase-helpers.sh b/bin/phase-helpers.sh
index 49b5547..0be79fd 100644
--- a/bin/phase-helpers.sh
+++ b/bin/phase-helpers.sh
@@ -456,6 +456,19 @@ unpack() {
__vecho unpack ${x}: file format not
recognized. Ignoring.
fi
;;
+ txz)
+ if ___eapi_unpack_is_case_sensitive \
+ [[ txz != * ${suffix} * ]] ; then
+ eqawarn QA Notice: unpack called with
\
+ suffix '${suffix}' which is
unofficially supported \
+ with EAPI '${EAPI}'. Instead
use 'txz'.
+ fi
+ if ___eapi_supports_txz; then
+ tar xoJf $srcdir$x || die $myfail
+ else
+ __vecho unpack ${x}: file format not
recognized. Ignoring.
+ fi
+ ;;
*)
__vecho unpack ${x}: file format not
recognized. Ignoring.
;;
--
2.0.4
[gentoo-portage-dev] [PATCHES] Initial EAPI6 patch set for review
Here are my patches drafting the first implementations of various parts of EAPI6, based on top of my cleaned up portage base (see the previous patch serie). Unless I've missed something, it includes all Council-approved items except for runtime USE, and additionally --docdir and --htmldir. Please review, comment and possibly test. The easy way: portage_LIVE_REPO=https://github.com/mgorny/portage.git portage_LIVE_BRANCH=eapi6 -- Michał Górny
[gentoo-portage-dev] [PATCH 08/13] Enable tentative support for EAPI6 profile-level directories
Enable the support for package.* and use.* directories on profile and repository level. --- pym/portage/eapi.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pym/portage/eapi.py b/pym/portage/eapi.py index 4f77910..7217d23 100644 --- a/pym/portage/eapi.py +++ b/pym/portage/eapi.py @@ -81,7 +81,7 @@ def eapi_supports_stable_use_forcing_and_masking(eapi): return eapi not in (0, 1, 2, 3, 4, 4-python, 4-slot-abi) def eapi_allows_directories_on_profile_level_and_repository_level(eapi): - return eapi in (4-python, 5-progress) + return eapi not in (0, 1, 2, 3, 4, 4-slot-abi, 5) def eapi_has_use_aliases(eapi): return eapi in (4-python, 5-progress) -- 2.0.4
[gentoo-portage-dev] [PATCH 10/13] Add tentative EAPI6 absolute path support to unpack()
Add support for absolute paths in unpack(). Allow subdirectory-level
relative paths not to start with './'.
---
bin/eapi.sh | 4
bin/phase-helpers.sh | 25 ++---
2 files changed, 22 insertions(+), 7 deletions(-)
diff --git a/bin/eapi.sh b/bin/eapi.sh
index 878f8e7..6716b1c 100644
--- a/bin/eapi.sh
+++ b/bin/eapi.sh
@@ -162,6 +162,10 @@ ___eapi_unpack_is_case_sensitive() {
[[ ${1-${EAPI}} =~ ^(0|1|2|3|4|4-python|4-slot-abi|5|5-hdepend)$ ]]
}
+___eapi_unpack_supports_absolute_paths() {
+ [[ ${1-${EAPI}} =~ ^(0|1|2|3|4|4-python|4-slot-abi|5|5-hdepend)$ ]]
+}
+
# OTHERS
___eapi_enables_failglob_in_global_scope() {
diff --git a/bin/phase-helpers.sh b/bin/phase-helpers.sh
index 0be79fd..60f7a39 100644
--- a/bin/phase-helpers.sh
+++ b/bin/phase-helpers.sh
@@ -276,14 +276,25 @@ unpack() {
y=${y##*.}
y_insensitive=$(LC_ALL=C tr [:upper:] [:lower:] ${y})
- if [[ ${x} == ./* ]] ; then
- srcdir=
- elif [[ ${x} == ${DISTDIR%/}/* ]] ; then
- die Arguments to unpack() cannot begin with
\${DISTDIR}.
- elif [[ ${x} == /* ]] ; then
- die Arguments to unpack() cannot be absolute
+ # wrt PMS 11.3.3.13 Misc Commands
+ if [[ ${x} != */* ]]; then
+ # filename without path of any kind
+ srcdir=${DISTDIR}/
+ elif [[ ${x} == ./* ]]; then
+ # relative path starting with './'
+ srcdir=
else
- srcdir=${DISTDIR}/
+ # non-'./' filename with path of some kind
+ if ___eapi_unpack_supports_absolute_paths; then
+ # EAPI 6 allows absolute and deep relative paths
+ srcdir=
+ elif [[ ${x} == ${DISTDIR%/}/* ]]; then
+ die Arguments to unpack() cannot begin with
\${DISTDIR} in EAPI ${EAPI}
+ elif [[ ${x} == /* ]] ; then
+ die Arguments to unpack() cannot be absolute
in EAPI ${EAPI}
+ else
+ die Relative paths to unpack() must be
prefixed with './' in EAPI ${EAPI}
+ fi
fi
[[ ! -s ${srcdir}${x} ]] die ${x} does not exist
--
2.0.4
[gentoo-portage-dev] [PATCH 11/13] Add tentative EAPI6 nonfatal support to die()
Add support for die() to respect 'nonfatal' modifier if
'--respect-nonfatal' (or '-n') option is used. This allows eclasses
to create custom ebuild helpers that mimic built-in helper behavior.
---
bin/eapi.sh | 4
bin/isolated-functions.sh | 7 +++
2 files changed, 11 insertions(+)
diff --git a/bin/eapi.sh b/bin/eapi.sh
index 6716b1c..c650a4c 100644
--- a/bin/eapi.sh
+++ b/bin/eapi.sh
@@ -166,6 +166,10 @@ ___eapi_unpack_supports_absolute_paths() {
[[ ${1-${EAPI}} =~ ^(0|1|2|3|4|4-python|4-slot-abi|5|5-hdepend)$ ]]
}
+___eapi_die_can_respect_nonfatal() {
+ [[ ! ${1-${EAPI}} =~
^(0|1|2|3|4|4-python|4-slot-abi|5|5-hdepend|5-progress)$ ]]
+}
+
# OTHERS
___eapi_enables_failglob_in_global_scope() {
diff --git a/bin/isolated-functions.sh b/bin/isolated-functions.sh
index d41f0b3..f9bc90d 100644
--- a/bin/isolated-functions.sh
+++ b/bin/isolated-functions.sh
@@ -116,6 +116,13 @@ __helpers_die() {
die() {
local IFS=$' \t\n'
+ if ___eapi_die_can_respect_nonfatal; then
+ if [[ ${1} == -n || ${1} == --respect-nonfatal ]]; then
+ [[ ${PORTAGE_NONFATAL} == 1 ]] return 1
+ shift
+ fi
+ fi
+
set +e
if [ -n ${QA_INTERCEPTORS} ] ; then
# die was called from inside inherit. We need to clean up
--
2.0.4
[gentoo-portage-dev] [PATCH 13/13] Add tentative EAPI6 phase functions
---
bin/phase-functions.sh | 11 +++
bin/phase-helpers.sh | 18 ++
2 files changed, 29 insertions(+)
diff --git a/bin/phase-functions.sh b/bin/phase-functions.sh
index b7fb5d7..f2088bd 100644
--- a/bin/phase-functions.sh
+++ b/bin/phase-functions.sh
@@ -806,6 +806,17 @@ __ebuild_phase_funcs() {
declare -F src_install /dev/null || \
src_install() { default; }
fi
+
+ # defaults starting with EAPI 6
+ if ! has ${eapi} 2 3 4 4-python 4-slot-abi 5 5-progress
5-hdepend; then
+ [[ ${phase_func} == src_prepare ]] \
+ default_src_prepare() {
__eapi6_src_prepare; }
+ [[ ${phase_func} == src_install ]] \
+ default_src_install() {
__eapi6_src_install; }
+
+ declare -F src_prepare /dev/null || \
+ src_prepare() { default; }
+ fi
;;
esac
}
diff --git a/bin/phase-helpers.sh b/bin/phase-helpers.sh
index 2eada2f..e64fe8b 100644
--- a/bin/phase-helpers.sh
+++ b/bin/phase-helpers.sh
@@ -748,6 +748,24 @@ __eapi4_src_install() {
fi
}
+__eapi6_src_prepare() {
+ if [[ $(declare -p PATCHES) == declare -a * ]]; then
+ eapply ${PATCHES[@]}
+ elif [[ -n ${PATCHES} ]]; then
+ eapply ${PATCHES}
+ fi
+
+ eapply_user
+}
+
+__eapi6_src_install() {
+ if [[ -f Makefile || -f GNUmakefile || -f makefile ]] ; then
+ emake DESTDIR=${D} install
+ fi
+
+ einstalldocs
+}
+
# @FUNCTION: has_version
# @USAGE: [--host-root] DEPEND ATOM
# @DESCRIPTION:
--
2.0.4
[gentoo-portage-dev] [PATCH 12/13] Add tentative EAPI6 in_iuse() function
Add a function to query IUSE_EFFECTIVE for flags.
---
bin/eapi.sh| 4
bin/phase-helpers.sh | 16
pym/portage/eapi.py| 3 +++
pym/portage/package/ebuild/doebuild.py | 2 +-
4 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/bin/eapi.sh b/bin/eapi.sh
index c650a4c..e0ade02 100644
--- a/bin/eapi.sh
+++ b/bin/eapi.sh
@@ -80,6 +80,10 @@ ___eapi_has_eapply_user() {
[[ ! ${1-${EAPI}} =~
^(0|1|2|3|4|4-python|4-slot-abi|5|5-hdepend|5-progress)$ ]]
}
+___eapi_has_in_iuse() {
+ [[ ! ${1-${EAPI}} =~
^(0|1|2|3|4|4-python|4-slot-abi|5|5-hdepend|5-progress)$ ]]
+}
+
___eapi_has_master_repositories() {
[[ ${1-${EAPI}} =~ ^(5-progress)$ ]]
}
diff --git a/bin/phase-helpers.sh b/bin/phase-helpers.sh
index 60f7a39..2eada2f 100644
--- a/bin/phase-helpers.sh
+++ b/bin/phase-helpers.sh
@@ -973,6 +973,22 @@ if ___eapi_has_eapply_user; then
}
fi
+if ___eapi_has_in_iuse; then
+ in_iuse() {
+ local use=${1}
+
+ if [[ -z ${use} ]]; then
+ echo !!! in_iuse() called without a parameter. 2
+ echo !!! in_iuse USEFLAG 2
+ die in_iuse() called without a parameter
+ fi
+
+ local liuse=( ${IUSE_EFFECTIVE} )
+
+ has ${use} ${liuse[@]#[+-]}
+ }
+fi
+
if ___eapi_has_master_repositories; then
master_repositories() {
local output repository=$1 retval
diff --git a/pym/portage/eapi.py b/pym/portage/eapi.py
index 7217d23..386c81d 100644
--- a/pym/portage/eapi.py
+++ b/pym/portage/eapi.py
@@ -68,6 +68,9 @@ def eapi_has_required_use_at_most_one_of(eapi):
def eapi_has_use_dep_defaults(eapi):
return eapi not in (0, 1, 2, 3)
+def eapi_has_in_iuse(eapi):
+ return eapi not in (0, 1, 2, 3, 4, 4-python, 4-slot-abi,
5, 5-progress)
+
def eapi_has_repo_deps(eapi):
return eapi in (4-python, 5-progress)
diff --git a/pym/portage/package/ebuild/doebuild.py
b/pym/portage/package/ebuild/doebuild.py
index 01707ae..29fb0df 100644
--- a/pym/portage/package/ebuild/doebuild.py
+++ b/pym/portage/package/ebuild/doebuild.py
@@ -54,7 +54,7 @@ from portage.dep import Atom, check_required_use, \
from portage.eapi import eapi_exports_KV, eapi_exports_merge_type, \
eapi_exports_replace_vars, eapi_exports_REPOSITORY, \
eapi_has_required_use, eapi_has_src_prepare_and_src_configure, \
- eapi_has_pkg_pretend, _get_eapi_attrs
+ eapi_has_pkg_pretend, _get_eapi_attrs, eapi_has_in_iuse
from portage.elog import elog_process, _preload_elog_modules
from portage.elog.messages import eerror, eqawarn
from portage.exception import DigestException, FileNotFound, \
--
2.0.4
