[gentoo-dev] Re: Live source based ebuild proposals
Ryan Hill posted 20090213191923.7fb35...@halo.dirtyepic.sk.ca, excerpted below, on Fri, 13 Feb 2009 19:19:23 -0600: > I'm sorry, Luca, but I can't do what I want to do with your proposal. > With the -scm suffix I can. Please, where's the concrete "Tell me how to do X with your proposal. With Y alternative, it could be handled this way. " ? We won't get anywhere with vague allusions to "what I want". ... -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
[gentoo-dev] Re: Live source based ebuild proposals
Ciaran McCreesh posted 2009021333.40efa...@snowmobile, excerpted below, on Fri, 13 Feb 2009 22:22:33 +: >> > How do I track an upstream who has a 0.34 branch (which is equal to >> > or ahead of the most recent 0.34.x release) a 0.36 branch (which is >> > equal to or ahead of the most recent 0.36.x release) >> >> In those cases is enough take the package version and add one w/out >> requiring any additional version component... > > Be specific. Explain how this works when, say, 0.34.4 is current, you > have a 0.34.5_live and 0.34.5 comes out. Luca, I didn't follow this bit either. The way I read your "add one" Ciaran's example went off the mark, but then my read didn't work too well either, so if you could fill in the concrete numbers you had in mind, it will hopefully clarify things. (Add one /where/, to which segment of the version?) Being as concrete in the examples as possible helps. It might seem to go on needlessly, but when the alternative is not being sure what you were talking about and thus possibly going off on a tangent... To Ciaran's credit, he's at least using concrete version numbers/strings in his examples, so there's no mistaking what he had in mind. Unfortunately, without this concreteness I think it's just going to be yet another argument in a circle, and I think/hope everybody's agreed there have been enough of those on this subject already. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
[gentoo-dev] Re: Live source based ebuild proposals
Ciaran McCreesh posted 20090213235351.381cf...@snowmobile, excerpted below, on Fri, 13 Feb 2009 23:53:51 +: [>> > Luca Barbato wrote...] >> >> Then if you continued to read you'll notice that >> > >> > ...you got so incoherent I gave up >> >> Relying to offense because I just pointed out something you dislikes >> since you cannot find a argumentative way reply isn't exactly polite or >> mature. > > No. Really. Again. You've been steadily talking nonsense on this whole > issue. Please step back, start again and clearly and concisely explain > in coherent English how you solve the simple example I gave earlier in > the thread. I am far from the only person who hasn't managed to work out > your explanation of this simple case so far. FWIW, while I'd not choose "incoherent" and "nonsense" as those are loaded terms that don't tend to make a productive debate if that is intended, I lost Luca's argument at this point as well. Now if it was just me I'd believe it was simply over my head. However, if a lead developer of one of our three package managers gets lost as well, maybe it isn't him, and maybe it isn't me. Somewhere, the logic thread simply got too difficult to follow and we're both lost. So Luca, I'd appreciate it too if you tried again from this point in the original stub-quoted above, as I really am trying to follow this. I don't have a position on this but I'd like to. =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
[gentoo-dev] Re: Live source based ebuild proposals
On Fri, 13 Feb 2009 23:53:51 + Ciaran McCreesh wrote: > On Sat, 14 Feb 2009 00:46:54 +0100 > Luca Barbato wrote: > > master is just a name, you may have the main development happen in > > another branch (say devel) and the stabler tree is kept on the > > master branch and you may want to track both as well. > > > > Or even worse, you get two lines of development you want to track > > that stay in completely different vcs. And that is the case of a > > real package, not theory. In those cases having a template could > > help a bit, having -scm + useflag is exactly the same as having bare > > useflags and slots. > > Yes, sometimes upstreams are insane. Then we can't deal with them. > We're aiming to handle the large majority of sensible cases here, not > the things that don't map onto version concepts in any way. > > > >> Then if you continued to read you'll notice that > > > > > > ...you got so incoherent I gave up trying to work out what you're > > > on about. You still haven't shown how to solve the simple example > > > I gave earlier in the thread. > > > > Relying to offense because I just pointed out something you > > dislikes since you cannot find a argumentative way reply isn't > > exactly polite or mature. > > No. Really. Again. You've been steadily talking nonsense on this whole > issue. Please step back, start again and clearly and concisely explain > in coherent English how you solve the simple example I gave earlier in > the thread. I am far from the only person who hasn't managed to work > out your explanation of this simple case so far. I'm sorry, Luca, but I can't do what I want to do with your proposal. With the -scm suffix I can. Actually I thought this was settled. What exactly is the issue holding GLEP 54 back that we need more discussion and different proposals? -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Live source based ebuild proposals
On Sat, 14 Feb 2009 00:46:54 +0100 Luca Barbato wrote: > master is just a name, you may have the main development happen in > another branch (say devel) and the stabler tree is kept on the master > branch and you may want to track both as well. > > Or even worse, you get two lines of development you want to track > that stay in completely different vcs. And that is the case of a real > package, not theory. In those cases having a template could help a > bit, having -scm + useflag is exactly the same as having bare > useflags and slots. Yes, sometimes upstreams are insane. Then we can't deal with them. We're aiming to handle the large majority of sensible cases here, not the things that don't map onto version concepts in any way. > >> Then if you continued to read you'll notice that > > > > ...you got so incoherent I gave up trying to work out what you're on > > about. You still haven't shown how to solve the simple example I > > gave earlier in the thread. > > Relying to offense because I just pointed out something you dislikes > since you cannot find a argumentative way reply isn't exactly polite > or mature. No. Really. Again. You've been steadily talking nonsense on this whole issue. Please step back, start again and clearly and concisely explain in coherent English how you solve the simple example I gave earlier in the thread. I am far from the only person who hasn't managed to work out your explanation of this simple case so far. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Live source based ebuild proposals
Ciaran McCreesh wrote: On Fri, 13 Feb 2009 23:35:34 +0100 Luca Barbato wrote: Hence -scm... that cannot do as well for more than a single target w/out using use flags. Because it isn't supposed to. Versions and topics are not the same thing, and treating topics as versions leads to mishandling. master is just a name, you may have the main development happen in another branch (say devel) and the stabler tree is kept on the master branch and you may want to track both as well. Or even worse, you get two lines of development you want to track that stay in completely different vcs. And that is the case of a real package, not theory. In those cases having a template could help a bit, having -scm + useflag is exactly the same as having bare useflags and slots. Then if you continued to read you'll notice that ...you got so incoherent I gave up trying to work out what you're on about. You still haven't shown how to solve the simple example I gave earlier in the thread. Relying to offense because I just pointed out something you dislikes since you cannot find a argumentative way reply isn't exactly polite or mature. -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] Re: Live source based ebuild proposals
On Fri, 13 Feb 2009 23:35:34 +0100 Luca Barbato wrote: > > Hence -scm... > > that cannot do as well for more than a single target w/out using use > flags. Because it isn't supposed to. Versions and topics are not the same thing, and treating topics as versions leads to mishandling. > Then if you continued to read you'll notice that ...you got so incoherent I gave up trying to work out what you're on about. You still haven't shown how to solve the simple example I gave earlier in the thread. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Live source based ebuild proposals
Ciaran McCreesh wrote: On Fri, 13 Feb 2009 23:17:03 +0100 Luca Barbato wrote: Ciaran McCreesh wrote: No, but something can represent the most commonly used models. We can't do -scm packages for upstreams that do utterly crazy stuff anyway, so we'll stick to the reasonably sane ones. So we stick to a subset we assume is what we'd expect from upstream. Yupyup. That was what we had in mind when we worked out -scm. Topic branches can be covered by use flags. So I cannot track mob, master and devel at the same time with -scm alone, I need to get useflag change deeply the ebuild behavior. If you're looking to track topics rather than versions, yes. Using versions to track topics gets extremely messy. How do I track an upstream who has a 0.34 branch (which is equal to or ahead of the most recent 0.34.x release) a 0.36 branch (which is equal to or ahead of the most recent 0.36.x release) In those cases is enough take the package version and add one w/out requiring any additional version component... Be specific. Explain how this works when, say, 0.34.4 is current, you have a 0.34.5_live and 0.34.5 comes out. and a master branch (which is ahead of any release) using the live property? The current versioning alone cannot do it cleanly. Hence -scm... that cannot do as well for more than a single target w/out using use flags. Then if you continued to read you'll notice that Luca Barbato wrote: > The same trick you'd use to track any number of independent branches > ahead any release could be used with the current versioning system to > archive the same result: use flags triggering the live property and > redefining the source accordingly (use live-master, use live-pu, use > live-mob) in every ebuild for said package. > > > So the bare minimum to keep the tree w/out "hand made infinity" (-) > is just use flags and property live as you just stated here, no strict > need for -scm for such task. I checked with zmedico and PROPERTIES > support conditionals so that is the _bare_ minimum to archive the use > case "I want to track a/any number of non version branch of a/any target > source controlled tree from upstream" -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] Re: Live source based ebuild proposals
On Fri, 13 Feb 2009 23:17:03 +0100 Luca Barbato wrote: > Ciaran McCreesh wrote: > > No, but something can represent the most commonly used models. We > > can't do -scm packages for upstreams that do utterly crazy stuff > > anyway, so we'll stick to the reasonably sane ones. > > So we stick to a subset we assume is what we'd expect from upstream. Yupyup. That was what we had in mind when we worked out -scm. > > Topic branches can be covered by use flags. > > So I cannot track mob, master and devel at the same time with -scm > alone, I need to get useflag change deeply the ebuild behavior. If you're looking to track topics rather than versions, yes. Using versions to track topics gets extremely messy. > > How do I track an upstream who has a 0.34 branch (which is equal to > > or ahead of the most recent 0.34.x release) a 0.36 branch (which > > is equal to or ahead of the most recent 0.36.x release) > > In those cases is enough take the package version and add one w/out > requiring any additional version component... Be specific. Explain how this works when, say, 0.34.4 is current, you have a 0.34.5_live and 0.34.5 comes out. > > and a master branch (which is ahead of any release) using the live > > property? > > The current versioning alone cannot do it cleanly. Hence -scm... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Live source based ebuild proposals
Ciaran McCreesh wrote: No, but something can represent the most commonly used models. We can't do -scm packages for upstreams that do utterly crazy stuff anyway, so we'll stick to the reasonably sane ones. So we stick to a subset we assume is what we'd expect from upstream. Topic branches can be covered by use flags. So I cannot track mob, master and devel at the same time with -scm alone, I need to get useflag change deeply the ebuild behavior. That could work fine also if upstream keeps two different version management systems (e.g lighttpd). 'pu' and 'master' both map onto a single foo-scm package. Version-wise, 'pu' and 'master' are both the same, and their version is greater than any existing release. GLEP 54 models this correctly. Given you do not want to track both at the same time, if you would like to track both of them you either do hack about this (that could work even with bare live property on pure versioning since you could say you could plainly stick use live in every ebuild and then make the ebuild directly fetch master, no matter which pv you get). In short any proposal that includes the "live property" gives you the same benefits. The live template proposal gives added value to the thing since it makes possible do more and something more useful since the reduced scope of interest tracking upstream has in the end. How do I track an upstream who has a 0.34 branch (which is equal to or ahead of the most recent 0.34.x release) a 0.36 branch (which is equal to or ahead of the most recent 0.36.x release) In those cases is enough take the package version and add one w/out requiring any additional version component... and a master branch (which is ahead of any release) using the live property? The current versioning alone cannot do it cleanly. A template approach or a "mark for infinity" version component like -scm can for a single release apart from a release target. But then you have to use the "use live-different-branch" to grant the same level of "version infinity" to different branches you may want to track. The same trick youd use to track any number of independent branches ahead any release could be used with the current versioning system to archive the same result: use flags triggering the live property and redefining the source accordingly (use live-master, use live-pu, use live-mob) in every ebuild for said package. So the bare minimum to keep the tree w/out "hand made infinity" (-) is just use flags and property live as you just stated here, no strict need for -scm for such task. I checked with zmedico and PROPERTIES support conditionals so that is the _bare_ minimum to archive the use case "I want to track a/any number of non version branch of a/any target source controlled tree from upstream" lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
[gentoo-dev] prepalldocs is now banned
Hi Everyone, This is a note that in the council meeting on 02/12/2009 the function 'prepalldocs' is banned for use in ebuilds with EAPIs 0 1 and 2. If you want some functionality from this function, please propose a new function or clearly defined behavior for prepalldocs for a *new* EAPI. Regards, Thomas Anderson -- - Thomas Anderson Gentoo Developer / Areas of responsibility: AMD64, Secretary to the Gentoo Council -
[gentoo-dev] Re: Live source based ebuild proposals Was: [gentoo-council] Council log and summary for meeting on 02/12/09
On Fri, 13 Feb 2009 21:29:32 +0100 Luca Barbato wrote: > > No it doesn't. _pre1, _pre2 etc does not accurately represent how > > upstream do releases. > > upstream is an undefined entity. We knows already upstreams that > follow a specific version numbering, that tag their release before > time and that even have playground branches where interesting&scary > thing happen, upstreams that keep everything on a single branch and > people doing something insane or worse. > > so NOTHING could represent something unpredictable. No, but something can represent the most commonly used models. We can't do -scm packages for upstreams that do utterly crazy stuff anyway, so we'll stick to the reasonably sane ones. > > And GLEP 54 solves the entire thing. > > It lets you have foo-scm tracking master, foo-2.0-scm tracking the > > 2.0 branch and foo-1.0-scm tracking the 1.0 branch, and the > > ordering all works correctly. It's the only solution anyone's come > > up with that gets this right. > > That doesn't cover the "pu" case brought up by ferdy or another case > in which you plan to track a branch that isn't a version branch or > hasn't a version target, if you want to be strict. So scm solve the > same problem _live solves or plain usage of "property live" within > current ebuilds solves. Topic branches can be covered by use flags. 'pu' and 'master' both map onto a single foo-scm package. Version-wise, 'pu' and 'master' are both the same, and their version is greater than any existing release. GLEP 54 models this correctly. > In short any proposal that includes the "live property" gives you the > same benefits. The live template proposal gives added value to the > thing since it makes possible do more and something more useful since > the reduced scope of interest tracking upstream has in the end. How do I track an upstream who has a 0.34 branch (which is equal to or ahead of the most recent 0.34.x release), a 0.36 branch (which is equal to or ahead of the most recent 0.36.x release) and a master branch (which is ahead of any release) using the live property? -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Live source based ebuild proposals Was: [gentoo-council] Council log and summary for meeting on 02/12/09
I moved the discussion on -dev since it should be the right place to discuss this. Ciaran McCreesh wrote: On Fri, 13 Feb 2009 20:33:31 +0100 Luca Barbato wrote: Ciaran McCreesh wrote: On Fri, 13 Feb 2009 18:20:34 +0100 Luca Barbato wrote: Live template provide correct ordering since generates ebuilds with a proper version. *sigh* Please stop pushing your epic fail of a non-solution until you understand the issue at hand. go back to 4chan. No. Really. You need to step back and think before you try to solve a problem. I focused on one of the issues I found in the current - and that your -scm proposal doesn't solve and that annoys me a bit. There is no way of using conventional version rules to accurately represent scm versions across multiple version-branches. _pre does not order correctly, since you don't know what the next release will be, and it collides with upstream release names. pre works perfectly fine with snapshots. No it doesn't. _pre1, _pre2 etc does not accurately represent how upstream do releases. upstream is an undefined entity. We knows already upstreams that follow a specific version numbering, that tag their release before time and that even have playground branches where interesting&scary thing happen, upstreams that keep everything on a single branch and people doing something insane or worse. so NOTHING could represent something unpredictable. you cannot track separate branches/versions w/out the very same issues you have merging separate versions of normal packages, and glep54 doesn't say anything about how it should track multiple branches in any different way than the current version components. Uh... There's no merging involved. Pardon, typo, I meant emerging. And GLEP 54 solves the entire thing. It lets you have foo-scm tracking master, foo-2.0-scm tracking the 2.0 branch and foo-1.0-scm tracking the 1.0 branch, and the ordering all works correctly. It's the only solution anyone's come up with that gets this right. That doesn't cover the "pu" case brought up by ferdy or another case in which you plan to track a branch that isn't a version branch or hasn't a version target, if you want to be strict. So scm solve the same problem _live solves or plain usage of "property live" within current ebuilds solves. In short any proposal that includes the "live property" gives you the same benefits. The live template proposal gives added value to the thing since it makes possible do more and something more useful since the reduced scope of interest tracking upstream has in the end. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
