[gentoo-dev] Live source based ebuild proposals Was: [gentoo-council] Council log and summary for meeting on 02/12/09

[gentoo-dev] Live source based ebuild proposals Was: [gentoo-council] Council log and summary for meeting on 02/12/09

[Luca Barbato]

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

[gentoo-dev] Re: Live source based ebuild proposals Was: [gentoo-council] Council log and summary for meeting on 02/12/09

[Ciaran McCreesh]

[-- 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 --]

Re: [gentoo-dev] Re: Live source based ebuild proposals

[Luca Barbato]

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

Re: [gentoo-dev] Re: Live source based ebuild proposals

[Ciaran McCreesh]

[-- 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 --]

Re: [gentoo-dev] Re: Live source based ebuild proposals

[Luca Barbato]

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

Re: [gentoo-dev] Re: Live source based ebuild proposals

[Ciaran McCreesh]

[-- 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 --]

Re: [gentoo-dev] Re: Live source based ebuild proposals

[Luca Barbato]

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

Re: [gentoo-dev] Re: Live source based ebuild proposals

[Ciaran McCreesh]

[-- 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 --]

[gentoo-dev] Re: Live source based ebuild proposals

[Ryan Hill]

[-- 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 --]

[gentoo-dev] Re: Live source based ebuild proposals

[Duncan]

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

Re: [gentoo-dev] Re: Live source based ebuild proposals

[Luca Barbato]

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

[gentoo-dev] Re: Live source based ebuild proposals

[Duncan]

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

Re: [gentoo-dev] Re: Live source based ebuild proposals

[Luca Barbato]

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

[gentoo-dev] Re: Live source based ebuild proposals

[Duncan]

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

Re: [gentoo-dev] Re: Live source based ebuild proposals

[Luca Barbato]

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

[gentoo-dev] Re: Live source based ebuild proposals

[Duncan]

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