Re: [gentoo-dev] new `usex` helper
On 09:37 Wed 21 Sep , Alec Warner wrote: On Wed, Sep 21, 2011 at 6:11 AM, Donnie Berkholz dberkh...@gentoo.org wrote: Not really, because when you update a bundled lib you actually make your whole app compile with it. People change the APIs of eclasses and then just let every internal consumer (ebuilds in gentoo-x86) break. Maybe if we put the burden on the one who changed the API, like the Linux kernel model, it would bother me less. I think people do this for three reasons. 1) There are no refactoring tools that I know of for bash. 2) There exist some package maintainers that will yell at you if you touch their packages for any reason. To refer to the Linux model again, you send patches to the maintainers, and they just commit them. This is much less effort than figuring out to handle some incomprehensible change to an already weird eclass and then sorting out how to deal with it across 20 or 30 packages. 3) Breaking things means they get fixed. We have this notify - deprecate - break workflow; I actually don't mind it (but only because I've seen it used elsewhere.) I do, because I don't have time to deal with other people breaking my packages, whether they're in gentoo-x86, the science overlay, or my personal one. I've got more important things to deal with, within Gentoo and in the rest of my life. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpSPCiSQYwz8.pgp Description: PGP signature
Re: [gentoo-dev] new `usex` helper
On Thu, Sep 22, 2011 at 5:41 PM, Donnie Berkholz dberkh...@gentoo.org wrote: On 09:37 Wed 21 Sep , Alec Warner wrote: On Wed, Sep 21, 2011 at 6:11 AM, Donnie Berkholz dberkh...@gentoo.org wrote: Not really, because when you update a bundled lib you actually make your whole app compile with it. People change the APIs of eclasses and then just let every internal consumer (ebuilds in gentoo-x86) break. Maybe if we put the burden on the one who changed the API, like the Linux kernel model, it would bother me less. I think people do this for three reasons. 1) There are no refactoring tools that I know of for bash. 2) There exist some package maintainers that will yell at you if you touch their packages for any reason. To refer to the Linux model again, you send patches to the maintainers, and they just commit them. This is much less effort than figuring out to handle some incomprehensible change to an already weird eclass and then sorting out how to deal with it across 20 or 30 packages. In my experience maintainers do not 'just commit my patches.' But perhaps I'm crazy. 3) Breaking things means they get fixed. We have this notify - deprecate - break workflow; I actually don't mind it (but only because I've seen it used elsewhere.) I do, because I don't have time to deal with other people breaking my packages, whether they're in gentoo-x86, the science overlay, or my personal one. I've got more important things to deal with, within Gentoo and in the rest of my life. You don't have time to fix breakages but you have time to do code reviews? I put a code review system in the infra survey because I think bugzilla is a poor way to track changes to the tree and there is not a good way to get feedback or track updates. I think if we had streamlined tools for this I'd be less concerned about mailing out changes to 60 or 100 or 1000 packages and having any sane idea which packages were fixed, which were pending, which packages I had not heard from someone in a while.. etc... -A -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com
Re: [gentoo-dev] new `usex` helper
On 18:04 Thu 22 Sep , Alec Warner wrote: On Thu, Sep 22, 2011 at 5:41 PM, Donnie Berkholz dberkh...@gentoo.org wrote: I do, because I don't have time to deal with other people breaking my packages, whether they're in gentoo-x86, the science overlay, or my personal one. I've got more important things to deal with, within Gentoo and in the rest of my life. You don't have time to fix breakages but you have time to do code reviews? If someone else I trust makes the changes and tells me they work, I can review code in an email on my cell phone in 15 seconds. I have to be on my single dev laptop with Gentoo repos and have a good 15 *minutes* to spare to figure out all the changes required, make them, test them, and do the commit. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpwzQq4wvFJa.pgp Description: PGP signature
Re: [gentoo-dev] new `usex` helper
On 14:20 Tue 20 Sep , Brian Harring wrote:
On Sun, Sep 18, 2011 at 10:16:46PM -0500, Donnie Berkholz wrote:
OK, so the implication of what you're saying is that everything in
eutils.eclass, base.eclass, toolchain-funcs.eclass,
flag-o-matic.eclass, versionator.eclass, multilib.eclass,
prefix.eclass, savedconfig.eclass, and maybe even linux-info.eclass
and autotools{,-utils}.eclass should go into EAPI. All that stuff is
pretty generally useful features.
Approximately... yes. Some of that (base.eclass for example) is EAPI
compatibility that can't be folded in (would require retroactively
addding to an EAPI), others aren't yet stabilized (true multilib for
example, seems to still be under discussion), etc.
You get the jist.
Yep, and I'm completely on the opposite end of the spectrum. =)
They should, but api compatibility of an eclass *can* be fluid- in
the past it was a locked API purely because of portage environment
saving issues. That's been resolved, there isn't any strict
requirement that the eclass maintain API compat now. You're
trying to rely on people doing best practices- for format building
blocks (use_with/usex/unpack/etc), that's not sane.
Which still pisses me off. It's like a shared library changing its
API without bumping SONAME.
I think you're viewing this wrong; if we're talking about openssl
breaking API/ABI w/out bumping soname, sure. It's one component that
is distributed alone, but consumed by others. There is no way to
atomically deploy the new API at the same time as all of the consumers
being updated for it.
That is /not/ the case of gentoo-x86; eclasses for us are equivalent
to bundled libs. Overlay stacking just makes it possible for a third
party component to reach in and use what is effectively an internal
lib.
Not really, because when you update a bundled lib you actually make your
whole app compile with it. People change the APIs of eclasses and then
just let every internal consumer (ebuilds in gentoo-x86) break. Maybe if
we put the burden on the one who changed the API, like the Linux kernel
model, it would bother me less.
--
Thanks,
Donnie
Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com
pgp6JYY1kT8uQ.pgp
Description: PGP signature
Re: [gentoo-dev] new `usex` helper
On Wed, Sep 21, 2011 at 6:11 AM, Donnie Berkholz dberkh...@gentoo.org wrote:
On 14:20 Tue 20 Sep , Brian Harring wrote:
On Sun, Sep 18, 2011 at 10:16:46PM -0500, Donnie Berkholz wrote:
OK, so the implication of what you're saying is that everything in
eutils.eclass, base.eclass, toolchain-funcs.eclass,
flag-o-matic.eclass, versionator.eclass, multilib.eclass,
prefix.eclass, savedconfig.eclass, and maybe even linux-info.eclass
and autotools{,-utils}.eclass should go into EAPI. All that stuff is
pretty generally useful features.
Approximately... yes. Some of that (base.eclass for example) is EAPI
compatibility that can't be folded in (would require retroactively
addding to an EAPI), others aren't yet stabilized (true multilib for
example, seems to still be under discussion), etc.
You get the jist.
Yep, and I'm completely on the opposite end of the spectrum. =)
They should, but api compatibility of an eclass *can* be fluid- in
the past it was a locked API purely because of portage environment
saving issues. That's been resolved, there isn't any strict
requirement that the eclass maintain API compat now. You're
trying to rely on people doing best practices- for format building
blocks (use_with/usex/unpack/etc), that's not sane.
Which still pisses me off. It's like a shared library changing its
API without bumping SONAME.
I think you're viewing this wrong; if we're talking about openssl
breaking API/ABI w/out bumping soname, sure. It's one component that
is distributed alone, but consumed by others. There is no way to
atomically deploy the new API at the same time as all of the consumers
being updated for it.
That is /not/ the case of gentoo-x86; eclasses for us are equivalent
to bundled libs. Overlay stacking just makes it possible for a third
party component to reach in and use what is effectively an internal
lib.
Not really, because when you update a bundled lib you actually make your
whole app compile with it. People change the APIs of eclasses and then
just let every internal consumer (ebuilds in gentoo-x86) break. Maybe if
we put the burden on the one who changed the API, like the Linux kernel
model, it would bother me less.
I think people do this for three reasons.
1) There are no refactoring tools that I know of for bash.
2) There exist some package maintainers that will yell at you if you
touch their packages for any reason.
3) Breaking things means they get fixed.
We have this notify - deprecate - break workflow; I actually don't
mind it (but only because I've seen it used elsewhere.)
-A
--
Thanks,
Donnie
Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com
Re: [gentoo-dev] new `usex` helper
since there's been no new feedback in a while, i'll add this to eutils.eclass
in a while:
usex() { use $1 echo ${2-yes}$4 || echo ${3-no}$5 ; }
then once it hits the PMS, i'll put EAPI wrapping around it.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] new `usex` helper
On Sun, Sep 18, 2011 at 10:16:46PM -0500, Donnie Berkholz wrote:
On 04:22 Sun 18 Sep , Brian Harring wrote:
On Sat, Sep 17, 2011 at 10:59:08PM -0500, Donnie Berkholz wrote:
On 13:43 Fri 16 Sep , Brian Harring wrote:
What I said from the getgo and you're missing is that pushing EAPI
implementation into the tree and ignoring EAPI, or having this notion
that every repository must automatically use gentoo-x86 (pushing the
format into the tree) is /wrong/;
I'm not necessarily requiring that every repository must automatically
use gentoo-x86 ??? just the ones that want to use features in an eclass
distributed with gentoo-x86. It sounds to me like the logical
consequence of what you're saying is that every useful function that's
now or could eventually be in an eclass must instead be incorporated
into EAPI. I guess I just don't see where you're drawing the line.
Drawing it back to what spawned it; usex. This isn't git.eclass, this
isn't svn.eclass, nor is it any of the other complex eclass
functionality. It's a core function that benefits the rest and should
be in EAPI.
OK, so the implication of what you're saying is that everything in
eutils.eclass, base.eclass, toolchain-funcs.eclass, flag-o-matic.eclass,
versionator.eclass, multilib.eclass, prefix.eclass, savedconfig.eclass,
and maybe even linux-info.eclass and autotools{,-utils}.eclass should go
into EAPI. All that stuff is pretty generally useful features.
Approximately... yes. Some of that (base.eclass for example) is EAPI
compatibility that can't be folded in (would require retroactively
addding to an EAPI), others aren't yet stabilized (true multilib for
example, seems to still be under discussion), etc.
You get the jist.
What I'm suggesting is that we should add useful stuff to eclasses
by default. If people want to use that stuff, they can stack on the
gentoo-x86 repo and inherit the eclass. I don't know why EAPI needs
to come into it at all.
Stacking on gentoo-x86 means you get *everything* for that repository.
If all you want is a random function out of eutils, that's a *lot* of
uncontrolled change to have intermixed with your overlays eclasses
(even worse, if the eclasses truly overlay into gentoo-x86, that
introduces compatibility issues there too).
Yeah, it seems like the ability to do partial stacking would be nice.
Perhaps to do so, one wouldn't stack by default but would have a way to
specify cross-repo dependencies (including eclasses) or file-specific
UUIDs of some sort.
We can specify cross repository dependencies (this repo needs
that repo) already via layout.conf; partial gets a bit messy, but may
be useful at the user level.
aside from meaning that the format definition can now *vary*,
which is great for wasting dev time and screwing up compatibility,
it opens up tweaking/customizing that functionality- aka,
fragmentation/divergence.
People doing that outside gentoo-x86 should do it the same way as
ones within it, by bumping the eclass to a new unique name. Ideally
one that's not just a numeric value so it won't conflict with ours,
in the same way as EAPI naming.
They should, but api compatibility of an eclass *can* be fluid- in the
past it was a locked API purely because of portage environment saving
issues. That's been resolved, there isn't any strict requirement that
the eclass maintain API compat now. You're trying to rely on people
doing best practices- for format building blocks
(use_with/usex/unpack/etc), that's not sane.
Which still pisses me off. It's like a shared library changing its API
without bumping SONAME.
I think you're viewing this wrong; if we're talking about openssl
breaking API/ABI w/out bumping soname, sure. It's one component that
is distributed alone, but consumed by others. There is no way to
atomically deploy the new API at the same time as all of the consumers
being updated for it.
That is /not/ the case of gentoo-x86; eclasses for us are equivalent
to bundled libs. Overlay stacking just makes it possible for a third
party component to reach in and use what is effectively an internal
lib.
This is even more true for repositories other than gentoo-x86;
gentoo-x86 is just in the weird position of being both public and
private.
That makes me wonder whether there's some way we
could enforce it, at least on the level of repoman or test suites to
examine whether the public interface changed, perhaps by generating a
cache of the interfaces and comparing to them.
Not without some doc/annotation of each function. The fact functions
are basically jump targets, w/ the function doing shift's/$@ to get at
it's args makes this very, very hard to introspect and validate.
Tests are the realistic option, or parsing an annotation defining the
functions prototype, caching that, and comparing it
Re: [gentoo-dev] new `usex` helper
On Sat, Sep 17, 2011 at 10:59:08PM -0500, Donnie Berkholz wrote: On 13:43 Fri 16 Sep , Brian Harring wrote: What I said from the getgo and you're missing is that pushing EAPI implementation into the tree and ignoring EAPI, or having this notion that every repository must automatically use gentoo-x86 (pushing the format into the tree) is /wrong/; I'm not necessarily requiring that every repository must automatically use gentoo-x86 ??? just the ones that want to use features in an eclass distributed with gentoo-x86. It sounds to me like the logical consequence of what you're saying is that every useful function that's now or could eventually be in an eclass must instead be incorporated into EAPI. I guess I just don't see where you're drawing the line. Drawing it back to what spawned it; usex. This isn't git.eclass, this isn't svn.eclass, nor is it any of the other complex eclass functionality. It's a core function that benefits the rest and should be in EAPI. That function is pretty clearly destined for EAPI, hence this long thread where you're bitching avoid EAPI, do eclass only and I'm bitching back that's stupid for xyz reasons, do a compat eclass and push it into the next EAPI. What I'm suggesting is that we should add useful stuff to eclasses by default. If people want to use that stuff, they can stack on the gentoo-x86 repo and inherit the eclass. I don't know why EAPI needs to come into it at all. Stacking on gentoo-x86 means you get *everything* for that repository. If all you want is a random function out of eutils, that's a *lot* of uncontrolled change to have intermixed with your overlays eclasses (even worse, if the eclasses truly overlay into gentoo-x86, that introduces compatibility issues there too). It's a matter of change control; using the unpack example again, if I'm maintaining a 6 month old snapshot for production deployment, which is preferable for getting an updated unpack function: 1) unpack is in eclasses; do I sync gentoo-x86 eclasses into my snapshot? Do I just cherry pick the updated function out, into my own trees? 2) if it's part of a new EAPI, do I cherry-pick the update for my $PM, and then use that EAPI in my ebuilds that needs that new functionality? #1 is exactly the sort of scenario where you'll start getting copy/pasting; you can state well they should just update, but that's completely unrealistic. Every production deployment of gentoo (or derived from) that I've seen has snapshot'd periodically for stabilization reasons. aside from meaning that the format definition can now *vary*, which is great for wasting dev time and screwing up compatibility, it opens up tweaking/customizing that functionality- aka, fragmentation/divergence. People doing that outside gentoo-x86 should do it the same way as ones within it, by bumping the eclass to a new unique name. Ideally one that's not just a numeric value so it won't conflict with ours, in the same way as EAPI naming. They should, but api compatibility of an eclass *can* be fluid- in the past it was a locked API purely because of portage environment saving issues. That's been resolved, there isn't any strict requirement that the eclass maintain API compat now. You're trying to rely on people doing best practices- for format building blocks (use_with/usex/unpack/etc), that's not sane. If we did the sort of thing you're basically pushing for, how long do you think it would be till funtoo added support for a new archive format to unpack? That's a *simple*, and *likely* example of how this can diverge. So, what I'm getting out of this is that we should make it harder for derivative distributions to innovate? Why should I care if they want to do stuff with new archive formats? If funtoo wants their own unpack, awesome. Shove it into an eclass under a different name. If they want to modify unpack /directly/, they better damn well change the EAPI the ebuild uses. prefix, kde, hell even a crazy python attempt have all had custom EAPI's built out for exactly scenarios like this. The point of EAPI is that it's an agreed to format. Embrace/extending it hasn't intentionally occured yet since the versioning is *designed* to allow for people to cut their own formats as needs be for experimentation. Further, doing as you propose means we're flat out, shit out of luck /ever/ distributing a usable cache for standalone repositories. If they're bound to the changes of another repository, distributing a cache in parallel is pointless (and not doable in current form since metadata/cache lacks necessary eclass validation data for overlay inheritance). Not much different from other cross-repository dependencies; you have to keep everything in lockstep because who knows what other people will do with their repos. Maybe people would want to distribute their own copies of forked dependent
Re: [gentoo-dev] new `usex` helper
On 04:22 Sun 18 Sep , Brian Harring wrote:
On Sat, Sep 17, 2011 at 10:59:08PM -0500, Donnie Berkholz wrote:
On 13:43 Fri 16 Sep , Brian Harring wrote:
What I said from the getgo and you're missing is that pushing EAPI
implementation into the tree and ignoring EAPI, or having this notion
that every repository must automatically use gentoo-x86 (pushing the
format into the tree) is /wrong/;
I'm not necessarily requiring that every repository must automatically
use gentoo-x86 ??? just the ones that want to use features in an eclass
distributed with gentoo-x86. It sounds to me like the logical
consequence of what you're saying is that every useful function that's
now or could eventually be in an eclass must instead be incorporated
into EAPI. I guess I just don't see where you're drawing the line.
Drawing it back to what spawned it; usex. This isn't git.eclass, this
isn't svn.eclass, nor is it any of the other complex eclass
functionality. It's a core function that benefits the rest and should
be in EAPI.
OK, so the implication of what you're saying is that everything in
eutils.eclass, base.eclass, toolchain-funcs.eclass, flag-o-matic.eclass,
versionator.eclass, multilib.eclass, prefix.eclass, savedconfig.eclass,
and maybe even linux-info.eclass and autotools{,-utils}.eclass should go
into EAPI. All that stuff is pretty generally useful features.
What I'm suggesting is that we should add useful stuff to eclasses
by default. If people want to use that stuff, they can stack on the
gentoo-x86 repo and inherit the eclass. I don't know why EAPI needs
to come into it at all.
Stacking on gentoo-x86 means you get *everything* for that repository.
If all you want is a random function out of eutils, that's a *lot* of
uncontrolled change to have intermixed with your overlays eclasses
(even worse, if the eclasses truly overlay into gentoo-x86, that
introduces compatibility issues there too).
Yeah, it seems like the ability to do partial stacking would be nice.
Perhaps to do so, one wouldn't stack by default but would have a way to
specify cross-repo dependencies (including eclasses) or file-specific
UUIDs of some sort.
aside from meaning that the format definition can now *vary*,
which is great for wasting dev time and screwing up compatibility,
it opens up tweaking/customizing that functionality- aka,
fragmentation/divergence.
People doing that outside gentoo-x86 should do it the same way as
ones within it, by bumping the eclass to a new unique name. Ideally
one that's not just a numeric value so it won't conflict with ours,
in the same way as EAPI naming.
They should, but api compatibility of an eclass *can* be fluid- in the
past it was a locked API purely because of portage environment saving
issues. That's been resolved, there isn't any strict requirement that
the eclass maintain API compat now. You're trying to rely on people
doing best practices- for format building blocks
(use_with/usex/unpack/etc), that's not sane.
Which still pisses me off. It's like a shared library changing its API
without bumping SONAME. That makes me wonder whether there's some way we
could enforce it, at least on the level of repoman or test suites to
examine whether the public interface changed, perhaps by generating a
cache of the interfaces and comparing to them.
I suspect an easier way to wrap this thread up is if you just state
what you want for backwards compatibility- in a seperate thread you
already proposed basically locking out systems older than 6 months,
and this discussion (moreso the eapi slows our development subtext)
is along the same lines.
Actually Zac said that, and I was trying to clarify if that's really
what he was saying. 9-12 months is more my feeling, as it gets extremely
difficult to maintain Gentoo systems without guru-level knowledge around
there. (Spoken as someone who still gets support emails from a couple of
previous positions.)
While I would like there to be a proper way to express repo-level
dependencies, properly announce deprecation and updates (e.g. to bash 4)
in advance as a feature integrated with the PM, and so on, I don't think
we should block our ability to move forward on these things. The
situation is essentially the same as it's always been, but our old
solution is no longer considered good enough and we don't have a new one
in place, so we're just sitting here.
Layout what you think it should be,
Layout of what, exactly?
how you think EAPI should be managed (what goes in, what doesn't,
etc),
If it can go in an eclass without strange contortions, put it there.
how derivatives should be handled,
With white gloves. More seriously, people making derivatives should have
maximal freedom to experiment, and I'm guessing most of them don't want
to deal with modifying 3 different PMs written at least partially in 3
different
Re: [gentoo-dev] new `usex` helper
On 09/16/2011 02:06 AM, Brian Harring wrote: On Thu, Sep 15, 2011 at 10:00:19PM -0500, Donnie Berkholz wrote: On 17:29 Wed 14 Sep , Brian Harring wrote: On Wed, Sep 14, 2011 at 02:16:41PM -0500, Donnie Berkholz wrote: On 19:14 Tue 13 Sep , Brian Harring wrote: On Tue, Sep 13, 2011 at 09:02:28PM -0500, Donnie Berkholz wrote: On 17:56 Tue 13 Sep , Mike Frysinger wrote: useful enough for EAPI ? or should i just stick it into eutils.eclass ? OR BOTH !? I prefer to avoid EAPI whenever possible, as it just makes things slower and more complex. Exactly the wrong approach; it winds up with master repositories/overlays cloning the functionality all over the damn place. Why are people cloning anything if it's in eutils.eclass in gentoo-x86? There are more repositories than just gentoo-x86, and overlay is *not* the only configuration in use. Who else besides you is using any other configuration? Should we really give a crap about the 0.001% population with some weird setup when we're trying to improve things for the 99.999% one? Specious argument; the point of controllable stacking was to avoid the issue of overlay's forcing their eclasses upon gentoo-x86 ebuilds (which may not support those modified eclasses) via the old PORTDIR_OVERLAY behaviour. This is why multiple repositories have layout.conf master definitions- to explicitly mark that they require/consume a seperate repo. What you're basically proposing is a variation of the push format definitions into a central tree, and require everyone to use that central tree. This discussion has come and gone; I say that being one of the folks who was *pushing for the repository solution*. The problem there is it fundamentally enables (more forces) fragmentation. Realistically I assume you're taking the stance EAPI gets in the way, lets do away with it- if so, well, out with it, and I'll dredge up the old logs/complaints that lead to EAPI. In the old days of the PM only handling a single overlay stack, what you're suggesting would be less heinous- heinous in detail, but pragmatic in reality. These days it's a regressive approach- requiring everyone to slave gentoo-x86 isn't sane, nor is avoiding eapi (resulting in people having to duplicate code into each repository stack). I don't know many people who aren't using gentoo-x86 or a repo that pulls in changes directly from it. rephrase please; either you're saying everyone uses gentoo-x86 which is sort of true (funtoo/chrome aren't necessarily riding HEAD/trunk however which means things can get ugly for derivative repository usage), but still ignores the situations where people have overlays w/ developmental eclasses that they need to selectively control where it overrides (which is where the notion of repo stacking comes into play). ~brian As I've mentioned in bug #380391 [1], a possible hybrid approach would be to distribute an eclass library that can be installed as a dependency of the package manager. This would provide benefits similar to those of using eclasses from gentoo-x86, while avoiding the introduction of a dependencies on either gentoo-x86 or package manager implementations. [1] https://bugs.gentoo.org/show_bug.cgi?id=380391#c3 -- Thanks, Zac
Re: [gentoo-dev] new `usex` helper
On 13:43 Fri 16 Sep , Brian Harring wrote: What I said from the getgo and you're missing is that pushing EAPI implementation into the tree and ignoring EAPI, or having this notion that every repository must automatically use gentoo-x86 (pushing the format into the tree) is /wrong/; I'm not necessarily requiring that every repository must automatically use gentoo-x86 — just the ones that want to use features in an eclass distributed with gentoo-x86. It sounds to me like the logical consequence of what you're saying is that every useful function that's now or could eventually be in an eclass must instead be incorporated into EAPI. I guess I just don't see where you're drawing the line. What I'm suggesting is that we should add useful stuff to eclasses by default. If people want to use that stuff, they can stack on the gentoo-x86 repo and inherit the eclass. I don't know why EAPI needs to come into it at all. aside from meaning that the format definition can now *vary*, which is great for wasting dev time and screwing up compatibility, it opens up tweaking/customizing that functionality- aka, fragmentation/divergence. People doing that outside gentoo-x86 should do it the same way as ones within it, by bumping the eclass to a new unique name. Ideally one that's not just a numeric value so it won't conflict with ours, in the same way as EAPI naming. If we did the sort of thing you're basically pushing for, how long do you think it would be till funtoo added support for a new archive format to unpack? That's a *simple*, and *likely* example of how this can diverge. So, what I'm getting out of this is that we should make it harder for derivative distributions to innovate? Why should I care if they want to do stuff with new archive formats? Further, doing as you propose means we're flat out, shit out of luck /ever/ distributing a usable cache for standalone repositories. If they're bound to the changes of another repository, distributing a cache in parallel is pointless (and not doable in current form since metadata/cache lacks necessary eclass validation data for overlay inheritance). Not much different from other cross-repository dependencies; you have to keep everything in lockstep because who knows what other people will do with their repos. Maybe people would want to distribute their own copies of forked dependent repositories too, I haven't thought much about it. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgptazUS3EHSs.pgp Description: PGP signature
Re: [gentoo-dev] new `usex` helper
On Thu, Sep 15, 2011 at 10:00:19PM -0500, Donnie Berkholz wrote: On 17:29 Wed 14 Sep , Brian Harring wrote: On Wed, Sep 14, 2011 at 02:16:41PM -0500, Donnie Berkholz wrote: On 19:14 Tue 13 Sep , Brian Harring wrote: On Tue, Sep 13, 2011 at 09:02:28PM -0500, Donnie Berkholz wrote: On 17:56 Tue 13 Sep , Mike Frysinger wrote: useful enough for EAPI ? or should i just stick it into eutils.eclass ? OR BOTH !? I prefer to avoid EAPI whenever possible, as it just makes things slower and more complex. Exactly the wrong approach; it winds up with master repositories/overlays cloning the functionality all over the damn place. Why are people cloning anything if it's in eutils.eclass in gentoo-x86? There are more repositories than just gentoo-x86, and overlay is *not* the only configuration in use. Who else besides you is using any other configuration? Should we really give a crap about the 0.001% population with some weird setup when we're trying to improve things for the 99.999% one? Specious argument; the point of controllable stacking was to avoid the issue of overlay's forcing their eclasses upon gentoo-x86 ebuilds (which may not support those modified eclasses) via the old PORTDIR_OVERLAY behaviour. This is why multiple repositories have layout.conf master definitions- to explicitly mark that they require/consume a seperate repo. What you're basically proposing is a variation of the push format definitions into a central tree, and require everyone to use that central tree. This discussion has come and gone; I say that being one of the folks who was *pushing for the repository solution*. The problem there is it fundamentally enables (more forces) fragmentation. Realistically I assume you're taking the stance EAPI gets in the way, lets do away with it- if so, well, out with it, and I'll dredge up the old logs/complaints that lead to EAPI. In the old days of the PM only handling a single overlay stack, what you're suggesting would be less heinous- heinous in detail, but pragmatic in reality. These days it's a regressive approach- requiring everyone to slave gentoo-x86 isn't sane, nor is avoiding eapi (resulting in people having to duplicate code into each repository stack). I don't know many people who aren't using gentoo-x86 or a repo that pulls in changes directly from it. rephrase please; either you're saying everyone uses gentoo-x86 which is sort of true (funtoo/chrome aren't necessarily riding HEAD/trunk however which means things can get ugly for derivative repository usage), but still ignores the situations where people have overlays w/ developmental eclasses that they need to selectively control where it overrides (which is where the notion of repo stacking comes into play). ~brian
Re: [gentoo-dev] new `usex` helper
On 02:06 Fri 16 Sep , Brian Harring wrote: Specious argument; the point of controllable stacking was to avoid the issue of overlay's forcing their eclasses upon gentoo-x86 ebuilds (which may not support those modified eclasses) via the old PORTDIR_OVERLAY behaviour. This is why multiple repositories have layout.conf master definitions- to explicitly mark that they require/consume a seperate repo. So let me get this straight — instead, you want overlay users to maintain a copy of every eclass they use, which will almost automatically become outdated and stale because it won't track the gentoo-x86 version? What you're basically proposing is a variation of the push format definitions into a central tree, and require everyone to use that central tree. This discussion has come and gone; I say that being one of the folks who was *pushing for the repository solution*. The problem there is it fundamentally enables (more forces) fragmentation. I think Gentoo will always provide one or a set of official central repositories, that's pretty much the definition of a distribution. So yes, I'm saying that generally useful stuff could go into one of these repositories, which (in the multi-repo case) could be like the eclass metaphor for repos; others would depend on it implicitly or explicitly. Realistically I assume you're taking the stance EAPI gets in the way, lets do away with it- if so, well, out with it, and I'll dredge up the old logs/complaints that lead to EAPI. I see EAPI as a nice thing for standardizing features that are implemented in the PM so they work identically across portage, pkgcore, and paludis. But I don't think that implementing things in the PM when they could go in an eclass is automatically the best choice. It dramatically slows down the speed of iteration, prototyping, and bug fixing. rephrase please; either you're saying everyone uses gentoo-x86 which is sort of true (funtoo/chrome aren't necessarily riding HEAD/trunk however which means things can get ugly for derivative repository usage), but still ignores the situations where people have overlays w/ developmental eclasses that they need to selectively control where it overrides (which is where the notion of repo stacking comes into play). I think I explained above, but let me know if that's not the case. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpQi7rzibDrE.pgp Description: PGP signature
Re: [gentoo-dev] new `usex` helper
On Fri, 16 Sep 2011 07:30:14 -0500 Donnie Berkholz dberkh...@gentoo.org wrote: Realistically I assume you're taking the stance EAPI gets in the way, lets do away with it- if so, well, out with it, and I'll dredge up the old logs/complaints that lead to EAPI. I see EAPI as a nice thing for standardizing features that are implemented in the PM so they work identically across portage, pkgcore, and paludis. But I don't think that implementing things in the PM when they could go in an eclass is automatically the best choice. It dramatically slows down the speed of iteration, prototyping, and bug fixing. What is more important is that it takes the code further from devs. I like to see the code I use, and be able to do anything about it if necessary. Not to see a spec and three different implementation, of which two use random hacks which I can't do anything about unless I start to implement PM-specific anti-hacks in my code. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] new `usex` helper
On Fri, Sep 16, 2011 at 7:04 AM, Michał Górny mgo...@gentoo.org wrote: On Fri, 16 Sep 2011 07:30:14 -0500 Donnie Berkholz dberkh...@gentoo.org wrote: Realistically I assume you're taking the stance EAPI gets in the way, lets do away with it- if so, well, out with it, and I'll dredge up the old logs/complaints that lead to EAPI. I see EAPI as a nice thing for standardizing features that are implemented in the PM so they work identically across portage, pkgcore, and paludis. But I don't think that implementing things in the PM when they could go in an eclass is automatically the best choice. It dramatically slows down the speed of iteration, prototyping, and bug fixing. What is more important is that it takes the code further from devs. I like to see the code I use, and be able to do anything about it if necessary. Not to see a spec and three different implementation, of which two use random hacks which I can't do anything about unless I start to implement PM-specific anti-hacks in my code. Just as an aside, every package mangler in Gentoo is open source. I don't see why you can't 'see' the code it is using. Now you might say 'ahhh C++ makes my eyes bleed' (as an aside, go read versionator eclass ;p) or 'eww portage is ugly' but every time I hear it I am less convinced that it is a good excuse. -- Best regards, Michał Górny
Re: [gentoo-dev] new `usex` helper
On Fri, Sep 16, 2011 at 07:30:14AM -0500, Donnie Berkholz wrote: On 02:06 Fri 16 Sep , Brian Harring wrote: Specious argument; the point of controllable stacking was to avoid the issue of overlay's forcing their eclasses upon gentoo-x86 ebuilds (which may not support those modified eclasses) via the old PORTDIR_OVERLAY behaviour. This is why multiple repositories have layout.conf master definitions- to explicitly mark that they require/consume a seperate repo. So let me get this straight — instead, you want overlay users to maintain a copy of every eclass they use, which will almost automatically become outdated and stale because it won't track the gentoo-x86 version? Where did I say that? layout.conf exists to allow repo's to explicitly state what they need- this means we can have individual overlay stacks, instead of having gentoo-x86, overlay1, overlay2, overlay3, with that as a single stack (including eclass lookup), it can be broken out as individual stacks. This limits the eclass affect for a repo to just what is explicitly configured. This is a good thing. This is controllable in addition. What I said from the getgo and you're missing is that pushing EAPI implementation into the tree and ignoring EAPI, or having this notion that every repository must automatically use gentoo-x86 (pushing the format into the tree) is /wrong/; aside from meaning that the format definition can now *vary*, which is great for wasting dev time and screwing up compatibility, it opens up tweaking/customizing that functionality- aka, fragmentation/divergence. If we did the sort of thing you're basically pushing for, how long do you think it would be till funtoo added support for a new archive format to unpack? That's a *simple*, and *likely* example of how this can diverge. Further, doing as you propose means we're flat out, shit out of luck /ever/ distributing a usable cache for standalone repositories. If they're bound to the changes of another repository, distributing a cache in parallel is pointless (and not doable in current form since metadata/cache lacks necessary eclass validation data for overlay inheritance). Fact is, gentoo-x86 has a lot of usable eclass in it, but it's not required to be used. Anything trying to *force* that is very short sighted and forgetting history. You want new EAPI functionality that is bash only? Awesome, eclass compatibility, and EAPI; don't just jam it into an eclass and say EAPI is slow/annoying and I don't want to do it. Do both, everyones happy. ~harring, cranky at revisiting the same arguments over and over
Re: [gentoo-dev] new `usex` helper
On 17:29 Wed 14 Sep , Brian Harring wrote: On Wed, Sep 14, 2011 at 02:16:41PM -0500, Donnie Berkholz wrote: On 19:14 Tue 13 Sep , Brian Harring wrote: On Tue, Sep 13, 2011 at 09:02:28PM -0500, Donnie Berkholz wrote: On 17:56 Tue 13 Sep , Mike Frysinger wrote: useful enough for EAPI ? or should i just stick it into eutils.eclass ? OR BOTH !? I prefer to avoid EAPI whenever possible, as it just makes things slower and more complex. Exactly the wrong approach; it winds up with master repositories/overlays cloning the functionality all over the damn place. Why are people cloning anything if it's in eutils.eclass in gentoo-x86? There are more repositories than just gentoo-x86, and overlay is *not* the only configuration in use. Who else besides you is using any other configuration? Should we really give a crap about the 0.001% population with some weird setup when we're trying to improve things for the 99.999% one? In the old days of the PM only handling a single overlay stack, what you're suggesting would be less heinous- heinous in detail, but pragmatic in reality. These days it's a regressive approach- requiring everyone to slave gentoo-x86 isn't sane, nor is avoiding eapi (resulting in people having to duplicate code into each repository stack). I don't know many people who aren't using gentoo-x86 or a repo that pulls in changes directly from it. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgp6FhfQzVVid.pgp Description: PGP signature
Re: [gentoo-dev] new `usex` helper
On Tue, 13 Sep 2011, Mike Frysinger wrote:
On Tuesday, September 13, 2011 19:08:09 Brian Harring wrote:
Making it overridable seems wiser-
usex() {
local flag=$1
local tval=${2-yes}
local fval=${3-no}
if use $flag; then
echo ${tval}
else
echo ${fval}
fi
}
Looks verbose. ;-)
i dont get it. mine already does exactly this, just in one line.
usex() { use $1 echo ${2:-yes} || echo ${3:-no} ; }
You should omit the colons though. ${2-yes} and ${3-no} will allow for
an explicit empty string as argument, whereas the :- variants won't.
Also quotes around the echo arguments can't harm.
Ulrich
Re: [gentoo-dev] new `usex` helper
On Wed, Sep 14, 2011 at 02:02, Ulrich Mueller wrote:
On Tue, 13 Sep 2011, Mike Frysinger wrote:
usex() { use $1 echo ${2:-yes} || echo ${3:-no} ; }
You should omit the colons though. ${2-yes} and ${3-no} will allow for
an explicit empty string as argument, whereas the :- variants won't.
in my original use, i wanted the :- behavior. but i can see how the -
behavior would be generally more flexible.
-mike
Re: [gentoo-dev] new `usex` helper
On 19:14 Tue 13 Sep , Brian Harring wrote: On Tue, Sep 13, 2011 at 09:02:28PM -0500, Donnie Berkholz wrote: On 17:56 Tue 13 Sep , Mike Frysinger wrote: useful enough for EAPI ? or should i just stick it into eutils.eclass ? OR BOTH !? I prefer to avoid EAPI whenever possible, as it just makes things slower and more complex. Exactly the wrong approach; it winds up with master repositories/overlays cloning the functionality all over the damn place. Why are people cloning anything if it's in eutils.eclass in gentoo-x86? -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpLbZB1u1CsQ.pgp Description: PGP signature
Re: [gentoo-dev] new `usex` helper
On 06:34 Wed 14 Sep , Ciaran McCreesh wrote: On Tue, 13 Sep 2011 21:02:28 -0500 Donnie Berkholz dberkh...@gentoo.org wrote: On 17:56 Tue 13 Sep , Mike Frysinger wrote: useful enough for EAPI ? or should i just stick it into eutils.eclass ? OR BOTH !? I prefer to avoid EAPI whenever possible, as it just makes things slower and more complex. Sticking it in an EAPI *shouldn't* be slow and more complex. There are three reasons why it is, and they should all be within Gentoo's ability to solve. [..reasons..] I'm glad we agree about its current state, whatever the reasons. While I wish I could do something about them, I can't at all in some cases or quickly in others. No matter what, it's going to be a slow process to change them, and I'd like to keep things like this from blocking on that. I'm hoping to fix some of the council-related issues with an updated GLEP 39 (WIP), but even being on the council doesn't help much in making others focus on productive issues. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpRPCNKacCwa.pgp Description: PGP signature
Re: [gentoo-dev] new `usex` helper
On Wed, Sep 14, 2011 at 02:16:41PM -0500, Donnie Berkholz wrote: On 19:14 Tue 13 Sep , Brian Harring wrote: On Tue, Sep 13, 2011 at 09:02:28PM -0500, Donnie Berkholz wrote: On 17:56 Tue 13 Sep , Mike Frysinger wrote: useful enough for EAPI ? or should i just stick it into eutils.eclass ? OR BOTH !? I prefer to avoid EAPI whenever possible, as it just makes things slower and more complex. Exactly the wrong approach; it winds up with master repositories/overlays cloning the functionality all over the damn place. Why are people cloning anything if it's in eutils.eclass in gentoo-x86? There are more repositories than just gentoo-x86, and overlay is *not* the only configuration in use. In the old days of the PM only handling a single overlay stack, what you're suggesting would be less heinous- heinous in detail, but pragmatic in reality. These days it's a regressive approach- requiring everyone to slave gentoo-x86 isn't sane, nor is avoiding eapi (resulting in people having to duplicate code into each repository stack). ~harring
Re: [gentoo-dev] new `usex` helper
On Tue, Sep 13, 2011 at 2:56 PM, Mike Frysinger vap...@gentoo.org wrote:
i keep writing little helpers like this in ebuilds:
usex() { use $1 echo ${2:-yes} || echo ${3:-no} ; }
usex...you naughty boy.
this is so i can do:
export some_var=$(usex some_flag)
and get it set to yes or no
If the intent is to use it for logic:
export some_var=$(usex some_flag)
if [[ $some_var == yes ]]; then
# buttsex
fi
Then I recommend making true / false the default and then doing
if $some_var; then
# buttsex
fi
If you are using it more like use_enable then...thats ok I guess ;p
-A
or if i want something a little different, i can do:
export some_var=$(usex some_flag true false)
export some_var=$(usex some_flag y n)
useful enough for EAPI ? or should i just stick it into eutils.eclass ? OR
BOTH !?
-mike
Re: [gentoo-dev] new `usex` helper
On Tue, Sep 13, 2011 at 06:13:10PM -0400, Mike Frysinger wrote:
On Tuesday, September 13, 2011 18:01:25 Alec Warner wrote:
On Tue, Sep 13, 2011 at 2:56 PM, Mike Frysinger wrote:
this is so i can do:
export some_var=$(usex some_flag)
and get it set to yes or no
If the intent is to use it for logic:
export some_var=$(usex some_flag)
if [[ $some_var == yes ]]; then
# buttsex
fi
that is not the intent
Then I recommend making true / false the default and then doing
if $some_var; then
# buttsex
fi
the point is to use it to construct vars that get passed to scripts like
econf
or programs like emake
ac_cv_some_header=$(usex foo) \
econf ...
emake USE_POOP=$(usex poo)
Making it overridable seems wiser-
usex() {
local flag=$1
local tval=${2-yes}
local fval=${3-no}
if use $flag; then
echo ${tval}
else
echo ${fval}
fi
}
While a bit longer, we likely can gut most of the use_* logic to
use that, and it makes it easier to deal w/ the situations where a
configure's options always assume --enable-blah thus don't export the
option, but *do* export a --disable-blah.
That way we can shift away from
$(use blah use_with blah)
to
$(usex blah --with-blah '')
Or that's the intent at least.
~brian
Re: [gentoo-dev] new `usex` helper
On 17:56 Tue 13 Sep , Mike Frysinger wrote: useful enough for EAPI ? or should i just stick it into eutils.eclass ? OR BOTH !? I prefer to avoid EAPI whenever possible, as it just makes things slower and more complex. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpi0BtNsnWIk.pgp Description: PGP signature
Re: [gentoo-dev] new `usex` helper
On Tue, Sep 13, 2011 at 09:02:28PM -0500, Donnie Berkholz wrote: On 17:56 Tue 13 Sep , Mike Frysinger wrote: useful enough for EAPI ? or should i just stick it into eutils.eclass ? OR BOTH !? I prefer to avoid EAPI whenever possible, as it just makes things slower and more complex. Exactly the wrong approach; it winds up with master repositories/overlays cloning the functionality all over the damn place. Do both. Specifically, do it right- get it into the format (so it can be relied on and isn't adhoc BS that proceeded EAPI), then push a compat implementation into eclasses for usage by EAPI's less than 5. You get the feature now, and it's sorted properly for moving forward. Not that complex. And yes I'm tired of people bitching about compatibility. I recall a similar group of folk bitching about the lack of compatibility prior to EAPI... it's annoying. /rant ~brian
Re: [gentoo-dev] new `usex` helper
On Tuesday, September 13, 2011 19:08:09 Brian Harring wrote:
Making it overridable seems wiser-
usex() {
local flag=$1
local tval=${2-yes}
local fval=${3-no}
if use $flag; then
echo ${tval}
else
echo ${fval}
fi
}
i dont get it. mine already does exactly this, just in one line.
usex() { use $1 echo ${2:-yes} || echo ${3:-no} ; }
While a bit longer, we likely can gut most of the use_* logic to
use that, and it makes it easier to deal w/ the situations where a
configure's options always assume --enable-blah thus don't export the
option, but *do* export a --disable-blah.
yeah, i thought about replacing use_{with,enable} with usex, but we'd have to
extend usex() a little bit more
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] new `usex` helper
On Tuesday, September 13, 2011 22:02:28 Donnie Berkholz wrote:
On 17:56 Tue 13 Sep , Mike Frysinger wrote:
useful enough for EAPI ? or should i just stick it into eutils.eclass
? OR BOTH !?
I prefer to avoid EAPI whenever possible, as it just makes things slower
and more complex.
should be easy to do both:
[[ ${EAPI} == [01234] ]] usex() { ... }
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] new `usex` helper
On Tue, Sep 13, 2011 at 10:45:27PM -0400, Mike Frysinger wrote:
On Tuesday, September 13, 2011 19:08:09 Brian Harring wrote:
Making it overridable seems wiser-
usex() {
local flag=$1
local tval=${2-yes}
local fval=${3-no}
if use $flag; then
echo ${tval}
else
echo ${fval}
fi
}
i dont get it. mine already does exactly this, just in one line.
usex() { use $1 echo ${2:-yes} || echo ${3:-no} ; }
Err. Mines prettier?
*cough*
Only real difference is ${2:-yes} versus ${2-yes}; the latter should
be used so that `usex flag '' '--disable-some-feature'` is usable.
While a bit longer, we likely can gut most of the use_* logic to
use that, and it makes it easier to deal w/ the situations where a
configure's options always assume --enable-blah thus don't export the
option, but *do* export a --disable-blah.
yeah, i thought about replacing use_{with,enable} with usex, but we'd have to
extend usex() a little bit more
Only extension I can think of is adding a prefix/postfix... which
frankly seems a bit too much. Anything else you were looking for?
To be clear, I'm more interested in this from the standpoint of making
econf invocations simpler- simplifying use_enable/use_with in the PM
isn't a huge concern to me since they're already pretty bloody
straightforward at this point.
~brian
