[gentoo-dev] Gentoo Council Reminder for February 26

[gentoo-dev] Gentoo Council Reminder for February 26

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 886 bytes --]

This is your friendly reminder! Same bat time (typically the 2nd & 4th 
Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @ 
irc.freenode.net) !

If you have something you'd wish for us to chat about, maybe even vote 
on, let us know! Simply reply to this e-mail for the whole Gentoo dev 
list to see.

Keep in mind that every GLEP *re*submission to the council for review 
must first be sent to the gentoo-dev mailing list 7 days (minimum) 
before being submitted as an agenda item which itself occurs 7 days 
before the meeting. Simply put, the gentoo-dev mailing list must be 
notified at least 14 days before the meeting itself.

For more info on the Gentoo Council, feel free to browse our homepage: 
http://www.gentoo.org/proj/en/council/

-- 
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Gentoo Council Reminder for February 26

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1656 bytes --]

On Sun, Feb 22, 2009 at 11:26:48PM -0800, Donnie Berkholz wrote:
> This is your friendly reminder! Same bat time (typically the 2nd & 4th 
> Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @ 
> irc.freenode.net) !

Informal request, but it would be useful to get an idea of the 
councils views on portage overlay compatibility issues.

Specifically, when it comes to gentoo repositories, there is one, and 
only one definition of what that is- pms's repo spec.  The problem 
here is that the only repository truly conformant to that spec is 
gentoo-x86, for the rest of the repositories (overlays realistically) 
whatever portage supports seems to be the eventual standard they grow 
towards.

Problem with this is that there is *zero* way to spot these non-pms 
repositories as it stands.  Simplest example, under portage overlays 
can unmask pkgs globally (gnome overlay reverting masks in 
gentoo-x86), package.unmask exists/works, package.keywords 
exists/works, and package.mask can be a directory.

I've not traced through the mess of config's __init__ to verify 
*every* pms noncompliance there, but I'd assume there are definitely a 
couple more hanging around to blow up in alt managers faces.

At the very least I'm after having the non-pms repos marked in some 
fashion so that alt implementations don't have to assume the portage 
standard (rather then the *agreed to* pms standard) to avoid 
exploding, but that's a rather short sighted solution- something is 
needed long term.

Either way, I'd be curious about the councils *informal* opinion on 
the overlay issue.

thanks,
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Gentoo Council Reminder for February 26

[Santiago M. Mola]

On Tue, Feb 24, 2009 at 6:47 PM, Brian Harring <ferringb@gmail.com> wrote:
>
> At the very least I'm after having the non-pms repos marked in some
> fashion so that alt implementations don't have to assume the portage
> standard (rather then the *agreed to* pms standard) to avoid
> exploding, but that's a rather short sighted solution- something is
> needed long term.
>

And/or make Portage noisy on PMS violations.

Regards,
-- 
Santiago M. Mola
Jabber ID: cooldwind@gmail.com

Re: [gentoo-dev] Gentoo Council Reminder for February 26

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 2238 bytes --]

On 23:26 Sun 22 Feb     , Donnie Berkholz wrote:
> This is your friendly reminder! Same bat time (typically the 2nd & 4th 
> Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @ 
> irc.freenode.net) !
> 
> If you have something you'd wish for us to chat about, maybe even vote 
> on, let us know! Simply reply to this e-mail for the whole Gentoo dev 
> list to see.

Here's the preliminary agenda. I'm running a bit behind on -dev, so it's 
a little out of date re GLEPs 54/55. People including lu_zero, cardoe, 
dev-zero, and tanderson should fill us in on things below that they've 
taken responsibility for. Anyone else can chime in anywhere!


Open council spot
-----------------

leio is next on the list. He's willing to join the council. A few of us 
already voted to confirm him on-list, and we're waiting on the others.

Goal: Vote to confirm him, if necessary.


GLEP 55 / bash version
----------------------

Crazy amounts of discussion on-list. Cardoe & Tiziano, you took 
responsibility for this -- can you sum up the current state of things? 
Pending something better, here's what I'd like to see happen on-list (or 
on the wiki, whatever) before the meeting:

Goal: Come up with 3 things:
	1) Agreement that this is a problem we need to solve now;
	2) Come up with a list of potential implementations;
	3) Come up with pros & cons for each.

At that point, we should have enough information to at least rank them 
and decide out whether the top-ranked one has the right approach. We 
should then clearly define any problems with it and suggest 
improvements.


GLEP 54: handling code from SCMs better
---------------------------------------

Some discussion on list. Luca, can you sum up the state of things?


PMS compliance in Gentoo-hosted trees besides gentoo-x86
--------------------------------------------------------

ferringb requested this. We need some discussion on-list before we talk 
about it during a meeting, so please chip in and reply to his post.


Suggestions are welcome, as are any summaries from our new secretary. =)

-- 
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Gentoo Council Reminder for February 26

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 1065 bytes --]

Donnie Berkholz wrote:
> On 23:26 Sun 22 Feb     , Donnie Berkholz wrote:
>> This is your friendly reminder! Same bat time (typically the 2nd & 4th 
>> Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @ 
>> irc.freenode.net) !
>>
>> If you have something you'd wish for us to chat about, maybe even vote 
>> on, let us know! Simply reply to this e-mail for the whole Gentoo dev 
>> list to see.
> 
> Here's the preliminary agenda. I'm running a bit behind on -dev, so it's 
> a little out of date re GLEPs 54/55. People including lu_zero, cardoe, 
> dev-zero, and tanderson should fill us in on things below that they've 
> taken responsibility for. Anyone else can chime in anywhere!
> 
> 
> Open council spot
> -----------------
> 
> leio is next on the list. He's willing to join the council. A few of us 
> already voted to confirm him on-list, and we're waiting on the others.
> 
> Goal: Vote to confirm him, if necessary.
> 

There already were enough votes (4/6 I think) to confirm him.

Regards,
Petteri



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

[gentoo-dev] Open council spot

[Torsten Veller]

* Petteri Räty <betelgeuse@gentoo.org>:
> Donnie Berkholz wrote:
> > Open council spot
> > -----------------
> > 
> > leio is next on the list. He's willing to join the council. A few of us 
> > already voted to confirm him on-list, and we're waiting on the others.
> > 
> > Goal: Vote to confirm him, if necessary.
> > 
> 
> There already were enough votes (4/6 I think) to confirm him.

GLEP 39 doesn't specify what happens when a member leaves. It does only
talk about slackers.

A former council decided to offer any open position to the next in line
and "if they accept and the current Council unanimously accepts the new
person, they get the position".
<http://www.gentoo.org/proj/en/council/meeting-logs/20070208-summary.txt>

4/6 is not "unanimously".

But...

This all was before "_reopen_nominations" was introduced. With
"_reopen_nominations" I don't see why the council needs to vote at all.


There might be a problem if another member leaves as the next two are
ranked equally.

Thanks

Re: [gentoo-dev] Gentoo Council Reminder for February 26

[Gilles Dartiguelongue]

Le mardi 24 février 2009 à 09:47 -0800, Brian Harring a écrit :
> On Sun, Feb 22, 2009 at 11:26:48PM -0800, Donnie Berkholz wrote:
> > This is your friendly reminder! Same bat time (typically the 2nd & 4th 
> > Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @ 
> > irc.freenode.net) !
> 
> Informal request, but it would be useful to get an idea of the 
> councils views on portage overlay compatibility issues.
> 
> Specifically, when it comes to gentoo repositories, there is one, and 
> only one definition of what that is- pms's repo spec.  The problem 
> here is that the only repository truly conformant to that spec is 
> gentoo-x86, for the rest of the repositories (overlays realistically) 
> whatever portage supports seems to be the eventual standard they grow 
> towards.
> 
> Problem with this is that there is *zero* way to spot these non-pms 
> repositories as it stands.  Simplest example, under portage overlays 
> can unmask pkgs globally (gnome overlay reverting masks in 
> gentoo-x86),

I reply here as part of the gnome herd and partly responsible for the
mask reverting in the overlay. I didn't know something used in
gentoo-x86 couldn't be used in an overlay. Could you point me to the
PMS section that treat this ?

-- 
Gilles Dartiguelongue <eva@gentoo.org>
Gentoo

Re: [gentoo-dev] Gentoo Council Reminder for February 26

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 2817 bytes --]

On Wed, Feb 25, 2009 at 01:42:38PM +0100, Gilles Dartiguelongue wrote:
> Le mardi 24 février 2009 à 09:47 -0800, Brian Harring a écrit :
> > On Sun, Feb 22, 2009 at 11:26:48PM -0800, Donnie Berkholz wrote:
> > > This is your friendly reminder! Same bat time (typically the 2nd & 4th 
> > > Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @ 
> > > irc.freenode.net) !
> > 
> > Informal request, but it would be useful to get an idea of the 
> > councils views on portage overlay compatibility issues.
> > 
> > Specifically, when it comes to gentoo repositories, there is one, and 
> > only one definition of what that is- pms's repo spec.  The problem 
> > here is that the only repository truly conformant to that spec is 
> > gentoo-x86, for the rest of the repositories (overlays realistically) 
> > whatever portage supports seems to be the eventual standard they grow 
> > towards.
> > 
> > Problem with this is that there is *zero* way to spot these non-pms 
> > repositories as it stands.  Simplest example, under portage overlays 
> > can unmask pkgs globally (gnome overlay reverting masks in 
> > gentoo-x86),
> 
> I reply here as part of the gnome herd and partly responsible for the
> mask reverting in the overlay. I didn't know something used in
> gentoo-x86 couldn't be used in an overlay.

Suspect I wasn't clear; you *can* use things from the parent (although 
that whole relationship is outside of PMS); the problem here is that 
y'all are reverting something in the *master*.

Literally, bug-buddy was masked in gentoo-x86; enabling your overlay 
reverts that masking in *gentoo-x86*.  Only reason this even works is 
due to portage internals being limited (everything is stacked 
together, no true standalones possible).

> Could you point me to the PMS section that treat this ?
Flip through the package.mask section (snagging from profiles.tex 
directly)-

"""
Note that the \t{-spec} syntax can be used to remove a mask in a 
parent profile, but not necessarily a global mask (from 
\t{profiles/package.mask}, section~\ref{profiles-package.mask}).

\note Portage currently treats \t{profiles/package.mask} as being on 
the leftmost branch of the inherit tree when it comes to \t{-lines}. 
This behaviour may not be relied upon.
"""

Note the 'parent profile'.  Why they're claiming repo level masking 
can't be reversed for that repo, not sure (reasonably sure several 
profiles rely on it).  Either way, your overlay is trying to revert 
entries it doesn't have in that stack.

Only reason it flies for portage is because it collapses it all into 
one stack; for managers designed to support multiple standalone repos 
that assumption no longer applies, thus that behaviour (outside of 
PMS) breaks.

~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Gentoo Council Reminder for February 26

[Nirbheek Chauhan]

On Mon, Feb 23, 2009 at 12:56 PM, Donnie Berkholz <dberkholz@gentoo.org> wrote:
> This is your friendly reminder! Same bat time (typically the 2nd & 4th
> Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @
> irc.freenode.net) !
>
> If you have something you'd wish for us to chat about, maybe even vote
> on, let us know! Simply reply to this e-mail for the whole Gentoo dev
> list to see.
>

This is an informal request for a peaceful compromise on a problem of
utmost importance which has the potential to turn into a massive
flame-war. Specifically, I'm referring to bug #256614. The latest
actions of a recently-recruited 'nirbheek' (belonging to the GNOME
herd) on the bug seem to leave the matter in a dicey situation.

Needless to say, this matter shadows all other topics on the council's
list, and must be resolved ASAP to dampen the inevitable clash of
titans. Perhaps the council meeting should be pre-poned to avert an
explosion of flaming posts the likes of which haven't been seen this
year... yet.

Humbly prostrating,

~Nirbheek_who_has_too_many_alter_egos Chauhan

--
Resident silly guy and troll

Re: [gentoo-dev] Gentoo Council Reminder for February 26

[Luca Barbato]

Donnie Berkholz wrote:
> Some discussion on list. Luca, can you sum up the state of things?

http://archives.gentoo.org/gentoo-dev/msg_81c676b7338c7c0dd10ce13b0e4684a2.xml

and

http://archives.gentoo.org/gentoo-dev/msg_22ecf185ab30a470fa7c26c06633d495.xml

Pretty much give you a summary, nothing much had been said probably 
because glep-54 has impact to a lesser number of people and thus is less 
interesting than the all encompassing glep-55.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

Re: [gentoo-dev] Gentoo Council Reminder for February 26

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 1769 bytes --]

On 23:12 Tue 24 Feb     , Donnie Berkholz wrote:
> Here's the preliminary agenda. I'm running a bit behind on -dev, so 
> it's a little out of date re GLEPs 54/55. People including lu_zero, 
> cardoe, dev-zero, and tanderson should fill us in on things below that 
> they've taken responsibility for. Anyone else can chime in anywhere!

I'm not prepared to decide on the whole set of solutions related to GLEP 
55 yet. I need more time to think about them, and since new options are 
showing up frequently, it makes that pretty hard. Here's what action I'd 
like to see regarding the whole thing:

Petteri, Tiziano, and Alec agree to work together to update & maintain a 
single document describing our requirements, the potential solutions, 
how well they address the requirements, and what the downsides (and any 
other upsides) are. If just 1-2 of them want to do this, that's fine 
too. All 3 of them have written something along these lines already, 
which is why I suggest them.


> GLEP 54: handling code from SCMs better
> ---------------------------------------
> 
> Some discussion on list. Luca, can you sum up the state of things?

Still waiting on a summary ... perhaps if Luca's too busy, our wonderful 
new secretary could do something along the lines of the above doc?



Making choices without a clear and straightforward comparison of options 
right next to each other is not the greatest. So the actions I propose 
for today's meeting are:

- Approve new council member

- Get people to agree to get a doc w/ requirements & comparisons for:
	- GLEP 54 (Luca or Thomas?)
	- GLEP 55 (Petteri/Tiziano/Alec)


-- 
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Gentoo Council Reminder for February 26

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 561 bytes --]

On Thu, 26 Feb 2009 11:19:20 -0800
> > GLEP 54: handling code from SCMs better
> > ---------------------------------------
> > 
> > Some discussion on list. Luca, can you sum up the state of things?
> 
> Still waiting on a summary ... perhaps if Luca's too busy, our
> wonderful new secretary could do something along the lines of the
> above doc?

Anyone but Luca please. Luca's been busy selectively ignoring problems
with his proposal, refusing to answer objections to it and claiming it
solves problems that it doesn't.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Gentoo Council Reminder for February 26

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 646 bytes --]

On 11:19 Thu 26 Feb     , Donnie Berkholz wrote:
> On 23:12 Tue 24 Feb     , Donnie Berkholz wrote:
> > GLEP 54: handling code from SCMs better
> > ---------------------------------------
> > 
> > Some discussion on list. Luca, can you sum up the state of things?
> 
> Still waiting on a summary

Sorry Luca, I missed what you posted. I do think we need something more 
like what I mentioned below, though.

> ... perhaps if Luca's too busy, our wonderful new secretary could do 
> something along the lines of the above doc?

-- 
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Gentoo Council Reminder for February 26

[Luca Barbato]

Ciaran McCreesh wrote:
> Anyone but Luca please. Luca's been busy selectively ignoring problems
> with his proposal, refusing to answer objections to it and claiming it
> solves problems that it doesn't.

My last two summaries got no replies from you so I guessed you were fine 
with them.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

Re: [gentoo-dev] Gentoo Council Reminder for February 26

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 870 bytes --]

On Thu, 26 Feb 2009 20:34:07 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > Anyone but Luca please. Luca's been busy selectively ignoring
> > problems with his proposal, refusing to answer objections to it and
> > claiming it solves problems that it doesn't.
> 
> My last two summaries got no replies from you so I guessed you were
> fine with them.

I'm still waiting for you to answer this:

> 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 this:

> 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] Gentoo Council Reminder for February 26

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 969 bytes --]

On Thu, Feb 26, 2009 at 11:19:20AM -0800, Donnie Berkholz wrote:
> On 23:12 Tue 24 Feb     , Donnie Berkholz wrote:
> > Here's the preliminary agenda. I'm running a bit behind on -dev, so 
> > it's a little out of date re GLEPs 54/55. People including lu_zero, 
> > cardoe, dev-zero, and tanderson should fill us in on things below that 
> > they've taken responsibility for. Anyone else can chime in anywhere!
> 
> I'm not prepared to decide on the whole set of solutions related to GLEP 
> 55 yet. I need more time to think about them, and since new options are 
> showing up frequently, it makes that pretty hard. Here's what action I'd 
> like to see regarding the whole thing:

A delay would actually be useful.  Folks (outside of the ml) have made 
some claims that can be disproven/proven via prototyping a pm.

I won't get it today, but week or so should be enough to nail down the 
performance cases, backwards compatibility, etc.

~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Gentoo Council Reminder for February 26

[Luca Barbato]

Ciaran McCreesh wrote:
> On Thu, 26 Feb 2009 20:34:07 +0100
> Luca Barbato <lu_zero@gentoo.org> wrote:
> I'm still waiting for you to answer this:
> 
>> 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.

being live working as substitute for 0.34.5_preN (_live) component the 
appearance of 0.34.5 will be higher than those. If we consider the .live 
alternative you'd have 0.34.live that is shadowed only by 0.35.x

That is pretty much the same you get with -scm, what happens is that in 
the case of live template you have portage installing 0.34.5_preN with 
revision informations and adding the template to the "live" set.

This way you can either emerge =0.34.5_preN or emerge @live depending on 
your needs. And you know that what you have installed since the 
information is available.

I replied in the summary but I guess I had been overly implicit =\

> and this:
> 
>> 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?

the live property doesn't tell much about versioning
so you could use 9999 as the "x" version component or .live or -scm,
the live property just makes portage aware that the sources are live.

This situation is one in those pkg-scm and pkg.live work better, but 
just for one branch.

As you said you could address the problem using useflags, so you could 
by extension you can use the same way to address the single case in 
proposals not supporting the tip of a single non version branch as well:

have the all the ebuilds in a package having IUSE=-live that if enabled 
triggers the live property and changes the src_uri to the live branch 
you desire.

Not exactly the nicest thing but having portage highlighting the case of 
live ebuilds on -p would maybe partially address it.

Again it had been answered in the summary anyway.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

Re: [gentoo-dev] Gentoo Council Reminder for February 26

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 2072 bytes --]

On Thu, 26 Feb 2009 21:40:26 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:
> >> 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.
> 
> being live working as substitute for 0.34.5_preN (_live) component
> the appearance of 0.34.5 will be higher than those. If we consider
> the .live alternative you'd have 0.34.live that is shadowed only by
> 0.35.x

So it doesn't work Right.

> That is pretty much the same you get with -scm, what happens is that
> in the case of live template you have portage installing 0.34.5_preN
> with revision informations and adding the template to the "live" set.

No, with -scm the order works correctly.

> >> 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?
> 
> the live property doesn't tell much about versioning
> so you could use 9999 as the "x" version component or .live or -scm,
> the live property just makes portage aware that the sources are live.
> 
> This situation is one in those pkg-scm and pkg.live work better, but 
> just for one branch.
> 
> As you said you could address the problem using useflags, so you
> could by extension you can use the same way to address the single
> case in proposals not supporting the tip of a single non version
> branch as well:
> 
> have the all the ebuilds in a package having IUSE=-live that if
> enabled triggers the live property and changes the src_uri to the
> live branch you desire.

So if you do that, how does the package manager know that one version
is less than another if a particular use flag is enabled, but greater
than it if it is disabled?

> Again it had been answered in the summary anyway.

I thought you had a better answer than "it doesn't work" that I was
just missing. Evidently not...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Regarding live sources management proposals (Was: [gentoo-dev] Gentoo Council Reminder for February 26)

[Luca Barbato]

Ciaran McCreesh wrote:
> On Thu, 26 Feb 2009 21:40:26 +0100
> Luca Barbato <lu_zero@gentoo.org> wrote:
>>>> 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.
>> being live working as substitute for 0.34.5_preN (_live) component
>> the appearance of 0.34.5 will be higher than those. If we consider
>> the .live alternative you'd have 0.34.live that is shadowed only by
>> 0.35.x
> 
> So it doesn't work Right.

I'd like to have more details on this point since it works the very same 
-scm does: the version component substituted gets higher than any other 
value when is resolved.

>> That is pretty much the same you get with -scm, what happens is that
>> in the case of live template you have portage installing 0.34.5_preN
>> with revision informations and adding the template to the "live" set.
> 
> No, with -scm the order works correctly.

"works correctly"

You are always not stating what correctly is in your opinion or why 
other solutions are broken.

In my opinion is correct to mark a version component as it will be the 
higher within that boundary, so 1.2.live means 1.2.x when x is the 
highest value, no matter which are the others at that time. Using a 
timestamp to replace x is the simplest way to grant this property.

>>>> 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?
>> the live property doesn't tell much about versioning
>> so you could use 9999 as the "x" version component or .live or -scm,
>> the live property just makes portage aware that the sources are live.
>>
>> This situation is one in those pkg-scm and pkg.live work better, but 
>> just for one branch.
>>
>> As you said you could address the problem using useflags, so you
>> could by extension you can use the same way to address the single
>> case in proposals not supporting the tip of a single non version
>> branch as well:
>>
>> have the all the ebuilds in a package having IUSE=-live that if
>> enabled triggers the live property and changes the src_uri to the
>> live branch you desire.
> 
> So if you do that, how does the package manager know that one version
> is less than another if a particular use flag is enabled, but greater
> than it if it is disabled?

The same argument is valid about the case of more than one tip branch 
you'd like to follow, how pkg-scm[master] is higher than pkg-scm[pu]?

With property live you just know that it was from a live sources, so you 
can consider it always new when it comes to resolve it and that pretty 
much gives you the same behavior you get out -scm as is detailed in the 
glep-54

With live template you know when you installed it and what you installed 
so you can re-emerge or update depending on what you want and you get at 
least the timestamp giving some more information.

If you throw in the mix SLOT alteration depending on or not on useflags 
or timestamps then you may also archive the property of having multiple 
version installed within any proposed framework. (e.g SLOT="$branch")

Still this is something could enjoy some more discussion.

As I stated long ago the main issue with the glep you proposed are the 
lack of informations in the document. You can fill every detail in 
mailing list as you like but if the document remains this way it doesn't 
get more informative.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero