* [gentoo-dev] Live source based ebuild proposals Was: [gentoo-council] Council log and summary for meeting on 02/12/09
[not found] ` <20090213194141.24d44a37@snowcone>
@ 2009-02-13 20:29 ` Luca Barbato
2009-02-13 20:37 ` [gentoo-dev] " Ciaran McCreesh
0 siblings, 1 reply; 16+ messages in thread
From: Luca Barbato @ 2009-02-13 20:29 UTC (permalink / raw
To: Ciaran McCreesh; +Cc: gentoo-dev
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 <lu_zero@gentoo.org> wrote:
>> Ciaran McCreesh wrote:
>>> On Fri, 13 Feb 2009 18:20:34 +0100
>>> Luca Barbato <lu_zero@gentoo.org> 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 -9999 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
^ permalink raw reply [flat|nested] 16+ messages in thread
* [gentoo-dev] Re: Live source based ebuild proposals Was: [gentoo-council] Council log and summary for meeting on 02/12/09
2009-02-13 20:29 ` [gentoo-dev] Live source based ebuild proposals Was: [gentoo-council] Council log and summary for meeting on 02/12/09 Luca Barbato
@ 2009-02-13 20:37 ` Ciaran McCreesh
2009-02-13 22:17 ` [gentoo-dev] Re: Live source based ebuild proposals Luca Barbato
0 siblings, 1 reply; 16+ messages in thread
From: Ciaran McCreesh @ 2009-02-13 20:37 UTC (permalink / raw
To: Luca Barbato; +Cc: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 2181 bytes --]
On Fri, 13 Feb 2009 21:29:32 +0100
Luca Barbato <lu_zero@gentoo.org> 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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-dev] Re: Live source based ebuild proposals
2009-02-13 20:37 ` [gentoo-dev] " Ciaran McCreesh
@ 2009-02-13 22:17 ` Luca Barbato
2009-02-13 22:22 ` Ciaran McCreesh
0 siblings, 1 reply; 16+ messages in thread
From: Luca Barbato @ 2009-02-13 22:17 UTC (permalink / raw
To: gentoo-dev
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" (-9999)
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-dev] Re: Live source based ebuild proposals
2009-02-13 22:17 ` [gentoo-dev] Re: Live source based ebuild proposals Luca Barbato
@ 2009-02-13 22:22 ` Ciaran McCreesh
2009-02-13 22:35 ` Luca Barbato
2009-02-14 2:38 ` Duncan
0 siblings, 2 replies; 16+ messages in thread
From: Ciaran McCreesh @ 2009-02-13 22:22 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 1389 bytes --]
On Fri, 13 Feb 2009 23:17:03 +0100
Luca Barbato <lu_zero@gentoo.org> 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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-dev] Re: Live source based ebuild proposals
2009-02-13 22:22 ` Ciaran McCreesh
@ 2009-02-13 22:35 ` Luca Barbato
2009-02-13 22:52 ` Ciaran McCreesh
2009-02-14 2:38 ` Duncan
1 sibling, 1 reply; 16+ messages in thread
From: Luca Barbato @ 2009-02-13 22:35 UTC (permalink / raw
To: gentoo-dev
Ciaran McCreesh wrote:
> On Fri, 13 Feb 2009 23:17:03 +0100
> Luca Barbato <lu_zero@gentoo.org> 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" (-9999)
> 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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-dev] Re: Live source based ebuild proposals
2009-02-13 22:35 ` Luca Barbato
@ 2009-02-13 22:52 ` Ciaran McCreesh
2009-02-13 23:46 ` Luca Barbato
0 siblings, 1 reply; 16+ messages in thread
From: Ciaran McCreesh @ 2009-02-13 22:52 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 560 bytes --]
On Fri, 13 Feb 2009 23:35:34 +0100
Luca Barbato <lu_zero@gentoo.org> 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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-dev] Re: Live source based ebuild proposals
2009-02-13 22:52 ` Ciaran McCreesh
@ 2009-02-13 23:46 ` Luca Barbato
2009-02-13 23:53 ` Ciaran McCreesh
0 siblings, 1 reply; 16+ messages in thread
From: Luca Barbato @ 2009-02-13 23:46 UTC (permalink / raw
To: gentoo-dev
Ciaran McCreesh wrote:
> On Fri, 13 Feb 2009 23:35:34 +0100
> Luca Barbato <lu_zero@gentoo.org> 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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-dev] Re: Live source based ebuild proposals
2009-02-13 23:46 ` Luca Barbato
@ 2009-02-13 23:53 ` Ciaran McCreesh
2009-02-14 1:19 ` Ryan Hill
` (2 more replies)
0 siblings, 3 replies; 16+ messages in thread
From: Ciaran McCreesh @ 2009-02-13 23:53 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 1545 bytes --]
On Sat, 14 Feb 2009 00:46:54 +0100
Luca Barbato <lu_zero@gentoo.org> 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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* [gentoo-dev] Re: Live source based ebuild proposals
2009-02-13 23:53 ` Ciaran McCreesh
@ 2009-02-14 1:19 ` Ryan Hill
2009-02-14 2:57 ` Duncan
2009-02-14 13:46 ` Luca Barbato
2009-02-14 2:28 ` Duncan
2009-02-14 14:41 ` Luca Barbato
2 siblings, 2 replies; 16+ messages in thread
From: Ryan Hill @ 2009-02-14 1:19 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 2149 bytes --]
On Fri, 13 Feb 2009 23:53:51 +0000
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> On Sat, 14 Feb 2009 00:46:54 +0100
> Luca Barbato <lu_zero@gentoo.org> 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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* [gentoo-dev] Re: Live source based ebuild proposals
2009-02-13 23:53 ` Ciaran McCreesh
2009-02-14 1:19 ` Ryan Hill
@ 2009-02-14 2:28 ` Duncan
2009-02-14 14:41 ` Luca Barbato
2 siblings, 0 replies; 16+ messages in thread
From: Duncan @ 2009-02-14 2:28 UTC (permalink / raw
To: gentoo-dev
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> posted
20090213235351.381cffcd@snowmobile, excerpted below, on Fri, 13 Feb 2009
23:53:51 +0000:
[>> > 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
^ permalink raw reply [flat|nested] 16+ messages in thread
* [gentoo-dev] Re: Live source based ebuild proposals
2009-02-13 22:22 ` Ciaran McCreesh
2009-02-13 22:35 ` Luca Barbato
@ 2009-02-14 2:38 ` Duncan
1 sibling, 0 replies; 16+ messages in thread
From: Duncan @ 2009-02-14 2:38 UTC (permalink / raw
To: gentoo-dev
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> posted
20090213222233.40efa9fd@snowmobile, excerpted below, on Fri, 13 Feb 2009
22:22:33 +0000:
>> > 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
^ permalink raw reply [flat|nested] 16+ messages in thread
* [gentoo-dev] Re: Live source based ebuild proposals
2009-02-14 1:19 ` Ryan Hill
@ 2009-02-14 2:57 ` Duncan
2009-02-14 13:46 ` Luca Barbato
1 sibling, 0 replies; 16+ messages in thread
From: Duncan @ 2009-02-14 2:57 UTC (permalink / raw
To: gentoo-dev
Ryan Hill <dirtyepic@gentoo.org> posted
20090213191923.7fb35b94@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. <version numbers,
specific real-case packages, code, whatever> " ?
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-dev] Re: Live source based ebuild proposals
2009-02-14 1:19 ` Ryan Hill
2009-02-14 2:57 ` Duncan
@ 2009-02-14 13:46 ` Luca Barbato
1 sibling, 0 replies; 16+ messages in thread
From: Luca Barbato @ 2009-02-14 13:46 UTC (permalink / raw
To: gentoo-dev
Ryan Hill wrote:
> I'm sorry, Luca, but I can't do what I want to do with your proposal.
I'd like to know what you want to do.
> With the -scm suffix I can.
Good to know, once you state what it is
> Actually I thought this was settled. What exactly is the issue holding
> GLEP 54 back that we need more discussion and different proposals?
- the glep 54 draft was deem unspecified and about 6 month ago. Peper
was asked by the council to add more details on why and how it is
useful. Nobody did anything and now he isn't even more acting as proxy
to Ciaranm requests.
- since apparently some people even disliked that proposal basically
because in their eyes it didn't add any to -9999 in term of
functionality people suggested to use a specific property to mark
ebuilds as "live" and have portage act accordingly.
- in addition some people (me being the main writer) started discussing
what really they needed that -9999 doesn't give already, focus being the
ability to track live sources installed and possibly the ability to get
from an ebuild using live sources to an ebuild using a snapshot
automatically. Thus the half baked document I put in my devspace got in.
If there weren't people quite vocal against -scm the council wouldn't
have been involved.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-dev] Re: Live source based ebuild proposals
2009-02-13 23:53 ` Ciaran McCreesh
2009-02-14 1:19 ` Ryan Hill
2009-02-14 2:28 ` Duncan
@ 2009-02-14 14:41 ` Luca Barbato
2009-02-15 8:05 ` Duncan
2009-02-15 10:55 ` Luca Barbato
2 siblings, 2 replies; 16+ messages in thread
From: Luca Barbato @ 2009-02-14 14:41 UTC (permalink / raw
To: gentoo-dev
Ciaran McCreesh wrote:
> 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.
Let try to clarify:
main problem:
- have the possibility to track upstream w/out having to take a manual
snapshot of their sources, but having portage automatically fetch them
from their tree.
current situation:
- we have some eclasses that on unpack phase fetch the sources from the
upstream server, prepare them and then the usual ebuild process follows.
- in order to make an ebuild using those eclasses be valued as the
highest possible, the simplest solution had been give it a version "high
enough", namely -9999. That makes simple track a single tree per package.
- The same could be done with any version component in order to try to
track multiple instances, so to track what will be the next 1.5 version,
somebody could create an ebuild as 1.4.9999 or 1.5_pre9999, 9999 being
an arbitrary big number.
-scm proposal:
- use a component version that makes whatever before it valued as "the
highest within that component", likely -r or _p do, that includes the
case "the highest version in absolute" in order to arbitrary decide an
"high enough" value, namely -9999.
- from what you can find in the glep, the change is apparently purely
cosmetic beside the hinted but not expressed possibilities having
portage fully aware those ebuild manage something "live" could give.
live-properity proposal:
- have a property to make portage aware that the ebuild is using live
sources.
- it doesn't add components to the ebuild version but just marks the
ebuild. So this proposal aims to improve portage internal management but
doesn't add or detract anything regarding version resolution.
live-template proposal:
- you still have a new version component, in this case either ".live" or
"_live", but in the template.
- it isn't used directly in resolution but it generates automatically a
normal version that get resolved as usual.
- tries to make sure there is a way to get reproducible results
regarding installed packages by embedding the informations to get again
the same sources. So you can also re-emerge the very same package again
you emerged it once since it has a defined version number.
- tries to give developers willing to track upstream and then provide
snapshots the ability to do that automatically.
I hope that is what the various proponents meant with their proposals
and that's clear enough.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
^ permalink raw reply [flat|nested] 16+ messages in thread
* [gentoo-dev] Re: Live source based ebuild proposals
2009-02-14 14:41 ` Luca Barbato
@ 2009-02-15 8:05 ` Duncan
2009-02-15 10:55 ` Luca Barbato
1 sibling, 0 replies; 16+ messages in thread
From: Duncan @ 2009-02-15 8:05 UTC (permalink / raw
To: gentoo-dev
Luca Barbato <lu_zero@gentoo.org> posted 4996D819.8080607@gentoo.org,
excerpted below, on Sat, 14 Feb 2009 15:41:29 +0100:
> Let try to clarify:
[picking this one to reply to, out of the two]
Thanks. That is much easier to follow. =:^)
--
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [gentoo-dev] Re: Live source based ebuild proposals
2009-02-14 14:41 ` Luca Barbato
2009-02-15 8:05 ` Duncan
@ 2009-02-15 10:55 ` Luca Barbato
1 sibling, 0 replies; 16+ messages in thread
From: Luca Barbato @ 2009-02-15 10:55 UTC (permalink / raw
To: gentoo-dev
Second step, shortcomings.
Luca Barbato wrote:
> main problem:
> - have the possibility to track upstream w/out having to take a manual
> snapshot of their sources, but having portage automatically fetch them
> from their tree.
This issue isn't and shouldn't something that touches directly our
normal users, tracking upstream isn't something a common user would do
for any software, upstream releases should be more than enough for
normal usage.
Keyword here being "normal".
Additional concern from ferdy is the fact you may want to track multiple
branches/repos for a software and those do not have a version target.
Ciaranm pointed out already that for such cases you may rely on useflags
to switch between tip repos/branches. I'm not sure useflag should
trigger slot changes (see discussions about binutils usage of useflags),
but still that is a simple and clean enough solution for a quite small
corner case.
Alternatively one could set a virtual and use different package names.
This solution is uglier but I guess would be ok for an overlay.
> current situation:
> - we have some eclasses that on unpack phase fetch the sources from the
> upstream server, prepare them and then the usual ebuild process follows.
> - in order to make an ebuild using those eclasses be valued as the
> highest possible, the simplest solution had been give it a version "high
> enough", namely -9999. That makes simple track a single tree per package.
> - The same could be done with any version component in order to try to
> track multiple instances, so to track what will be the next 1.5 version,
> somebody could create an ebuild as 1.4.9999 or 1.5_pre9999, 9999 being
> an arbitrary big number.
The main issues so far:
- you have to hand produce "high enough" version values
- you cannot track what did you install since you don't have such
information
- you cannot do reemerge (useful for revdep rebuilds)
- in order to refresh them you need either to rely on script or on sets
hand produced or heuristically defined ("all ebuilds that inherit eclass
svn go in svn set").
- since you fetch on unpack phase you cannot use emerge -f consistently
> -scm proposal:
> - use a component version that makes whatever before it valued as "the
> highest within that component", likely -r or _p do, that includes the
> case "the highest version in absolute" in order to arbitrary decide an
> "high enough" value, namely -9999.
> - from what you can find in the glep, the change is apparently purely
> cosmetic beside the hinted but not expressed possibilities having
> portage fully aware those ebuild manage something "live" could give.
The issues so far:
- it makes the definition of "high enough number" and marks ebuilds as
live but doesn't address the other issues
- the glep is quite implicit and doesn't tell enough
- it requires changes that aren't exactly low impact for almost no
return, at least apparently since the glep doesn't tell enough.
[I hope that explains better why this proposal had been on hold for this
long and why the main requirement to reconsider it had been to add more
informations in the glep]
> live-properity proposal:
> - have a property to make portage aware that the ebuild is using live
> sources.
> - it doesn't add components to the ebuild version but just marks the
> ebuild. So this proposal aims to improve portage internal management but
> doesn't add or detract anything regarding version resolution.
The issue so far:
- it just solves the fact ebuilds aren't marked as "live" but doesn't
address any of the other problems.
- it has little impact on portage but also gives a little in itself
[That makes this proposal interesting since you may build on it
solutions to the other issues with low impact as well]
> live-template proposal:
> - you still have a new version component, in this case either ".live" or
> "_live", but in the template.
> - it isn't used directly in resolution but it generates automatically a
> normal version that get resolved as usual.
> - tries to make sure there is a way to get reproducible results
> regarding installed packages by embedding the informations to get again
> the same sources. So you can also re-emerge the very same package again
> you emerged it once since it has a defined version number.
> - tries to give developers willing to track upstream and then provide
> snapshots the ability to do that automatically.
The issue so far:
- it tries to scratches all the itches at the same time.
- it could be as invasive as the -scm proposal but tries to address
every issue in order to make worthy doing such radical changes in one go.
- The proposal itself hasn't covered many implementation and usage
details yet.
[What puzzles me is that some people claims you cannot do something with
live templates while you can with -scm]
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2009-02-15 10:55 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20090212214925.GA21532@dodo.hsd1.nj.comcast.net>
[not found] ` <20090213155445.GA31550@dodo.hsd1.nj.comcast.net>
[not found] ` <4995ABE2.4000907@gentoo.org>
[not found] ` <20090213172725.34258824@snowcone>
[not found] ` <4995CB0B.80209@gentoo.org>
[not found] ` <20090213194141.24d44a37@snowcone>
2009-02-13 20:29 ` [gentoo-dev] Live source based ebuild proposals Was: [gentoo-council] Council log and summary for meeting on 02/12/09 Luca Barbato
2009-02-13 20:37 ` [gentoo-dev] " Ciaran McCreesh
2009-02-13 22:17 ` [gentoo-dev] Re: Live source based ebuild proposals Luca Barbato
2009-02-13 22:22 ` Ciaran McCreesh
2009-02-13 22:35 ` Luca Barbato
2009-02-13 22:52 ` Ciaran McCreesh
2009-02-13 23:46 ` Luca Barbato
2009-02-13 23:53 ` Ciaran McCreesh
2009-02-14 1:19 ` Ryan Hill
2009-02-14 2:57 ` Duncan
2009-02-14 13:46 ` Luca Barbato
2009-02-14 2:28 ` Duncan
2009-02-14 14:41 ` Luca Barbato
2009-02-15 8:05 ` Duncan
2009-02-15 10:55 ` Luca Barbato
2009-02-14 2:38 ` Duncan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox