[gentoo-dev] A few questions to our nominees

[gentoo-dev] A few questions to our nominees

[Piotr Jaroszyński]

Hello,

looks like every nominee wants the council to be more technical so I
have a few technical questions for you:

1. GLEP54
2. GLEP55
3. Most wanted changes in future EAPIs

[1] - http://www.gentoo.org/proj/en/glep/glep-0054.html
[2] - http://www.gentoo.org/proj/en/glep/glep-0055.html

-- 
Best Regards,
Piotr Jaroszyński

Re: [gentoo-dev] A few questions to our nominees

[Alistair Bush]

Piotr Jaroszyński wrote:
> Hello,
> 
> looks like every nominee wants the council to be more technical so I
> have a few technical questions for you:
> 
> 1. GLEP54
> 2. GLEP55
> 3. Most wanted changes in future EAPIs

4. Strategies to ensure that gentoo's package manager is able to 
quickly/smartly/sainly support future EAPI's, GLEP54, GLEP55?

> 
> [1] - http://www.gentoo.org/proj/en/glep/glep-0054.html
> [2] - http://www.gentoo.org/proj/en/glep/glep-0055.html
> 
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] A few questions to our nominees

[Fernando J. Pereda]

On 8 Jun 2008, at 11:12, Piotr Jaroszyński wrote:

> Hello,
>
> looks like every nominee wants the council to be more technical so I
> have a few technical questions for you:
>
> 1. GLEP54
> 2. GLEP55
> 3. Most wanted changes in future EAPIs
>
> [1] - http://www.gentoo.org/proj/en/glep/glep-0054.html
> [2] - http://www.gentoo.org/proj/en/glep/glep-0055.html

Hi,

I already argued in favour of both GLEP54 and GLEP55 in a council  
meeting. I'm eager to know what real problems people have with those.  
Until now, we've only seen stupid complains such as: 'changing  
extension breaks my shitty scripts', 'it looks weird', 'I don't  
understand what you are talking about, yet I want to comment', 'but  
scm means something else for me'...

Other than that, I'm looking forward to both GLEPs being accepted  
whether I make it to the council or not.

With respect to future EAPIs, from the top of my head, I'd like Gentoo  
to have:

    * USE dependencies.
    * Suggested dependencies.
    * Blockers information to the package manager.
    * Proper SCM integration with the package manager.

- ferdy--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] A few questions to our nominees

[Ferris McCormick]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 1657 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, 8 Jun 2008 11:12:27 +0200
"Piotr Jaroszyński" <peper@gentoo.org> wrote:

> Hello,
> 
> looks like every nominee wants the council to be more technical so I
> have a few technical questions for you:
> 
> 1. GLEP54
> 2. GLEP55
> 3. Most wanted changes in future EAPIs
> 
> [1] - http://www.gentoo.org/proj/en/glep/glep-0054.html
> [2] - http://www.gentoo.org/proj/en/glep/glep-0055.html
> 
> -- 
> Best Regards,
> Piotr Jaroszyński
> [Error decoding BASE64]

Sorry to disappoint you.  If you get me on council, I'm going to ask for
a recommendation and follow it unless it looks ridiculous.  For the
GLEPs you mentioned, unless someone came forward otherwise, I'd approve
them out of hand.  As for future EAPIs, that is not a council matter
that I can see.  Why on earth can't that be done at the level of those
who care?  I.e., people who implement package managers or want EAPIs.
It seems to me all we want is consistency, and council's job is to put
package manager people into a room and tell them not to come out until
they agree on something.  If I'm a councilor, I really don't care what
that is.

I'll listen to what you want for future EAPIs, but I don't think it's
council's job to decide.

Regards,
Ferris
- --
Ferris McCormick (P44646, MI) <fmccor@gentoo.org>
Developer, Gentoo Linux (Sparc, Devrel, Userrel, Trustees)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkhLqJMACgkQQa6M3+I///frwQCg3SmJMu9K9x3hjpx0jcc0tOBy
YpIAn2DS+YeYw016hoebhIyLKtbu80tE
=qDAl
-----END PGP SIGNATURE-----
éí¢‡^¾X¬¶È\x1ežÚ(¢¸&j)bž	b²

Re: [gentoo-dev] A few questions to our nominees

[Ferris McCormick]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, 8 Jun 2008 09:38:17 +0000
Ferris McCormick <fmccor@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Sun, 8 Jun 2008 11:12:27 +0200
> "Piotr Jaroszyński" <peper@gentoo.org> wrote:
> 
> > Hello,
> > 
> > looks like every nominee wants the council to be more technical so I
> > have a few technical questions for you:
> > 
> > 1. GLEP54
> > 2. GLEP55
> > 3. Most wanted changes in future EAPIs
> > 
> > [1] - http://www.gentoo.org/proj/en/glep/glep-0054.html
> > [2] - http://www.gentoo.org/proj/en/glep/glep-0055.html
> > 
> > -- 
> > Best Regards,
> > Piotr Jaroszyński
> > [Error decoding BASE64]
> 
> Sorry to disappoint you.  If you get me on council, I'm going to ask for
> a recommendation and follow it unless it looks ridiculous.  For the
> GLEPs you mentioned, unless someone came forward otherwise, I'd approve
> them out of hand.  As for future EAPIs, that is not a council matter
> that I can see.  Why on earth can't that be done at the level of those
> who care?  I.e., people who implement package managers or want EAPIs.
> It seems to me all we want is consistency, and council's job is to put
> package manager people into a room and tell them not to come out until
> they agree on something.  If I'm a councilor, I really don't care what
> that is.
> 
> I'll listen to what you want for future EAPIs, but I don't think it's
> council's job to decide.
> 
Sorry, I missed something.  This is probably a QA matter since they own
PMS, I believe. But it still is not a Council matter.  It's QA's job to
get an agreement on EAPIs if there is a problem.

>
Regards,
Ferris
- --
Ferris McCormick (P44646, MI) <fmccor@gentoo.org>
Developer, Gentoo Linux (Sparc, Devrel, Userrel, Trustees)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkhLslUACgkQQa6M3+I///fHlQCgjjzd35UA3ZzsV2VfVSz2BAo9
yhAAn3JHu/Y1hEcVqo4AVx+1Gwbv3zRI
=XM2p
-----END PGP SIGNATURE-----

Re: [gentoo-dev] A few questions to our nominees

[Roy Bamford]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2008.06.08 10:12, Piotr Jaroszyński wrote:
> Hello,
> 
> looks like every nominee wants the council to be more technical so I
> have a few technical questions for you:

[snip]

Like it or not, the council are our engineering managers, not detailed 
designers. The councils role is to broker agreement and promulgate 
standards once they have been agreed by those who have to work with 
them.

Looking back over the last council and its recent meetings, its clear 
that a lot of detailed design has been attempted at the meetings. 
That's because all engineering managers love to get some real 
engineering to do. 

Before the flames start lets consider the Package Manager Specification 
(PMS) as an example. For this (very black and white) illustration, 
forget the council discussions to date and imagine that representatives 
of all three package managers went to council and said in unison 
"We have agreed this specification". 
Are council really going to start picking holes in it and say no?
At the meeting ?

Council will have spent some time before the meeting reading it and 
running question and answer sessions with all interested parties, so at 
the meeting they can put it to a vote to record its formal adoption.
If this preparation showed were issues needing more work, it would be 
removed from the agenda unless there was a need for a public airing of 
the issues, then there would be a brief statement, not a long debate 
that tried to fix the issues there and then.

- -- 
Regards,

Roy Bamford
(NeddySeagoon) a member of
gentoo-ops
forum-mods
treecleaners
trustees
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkhLuG8ACgkQTE4/y7nJvasbtACgj8GgFrcFzQ3yY0QD6liq/Mar
na4AoKr4b5ZjuF0gQUgyL3m+lic4Dh9Q
=giiq
-----END PGP SIGNATURE-----

--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] A few questions to our nominees

[Denis Dupeyron]

On Sun, Jun 8, 2008 at 12:45 PM, Roy Bamford <neddyseagoon@gentoo.org> wrote:
> Before the flames start lets consider the Package Manager Specification
> (PMS) as an example. For this (very black and white) illustration,
> forget the council discussions to date and imagine that representatives
> of all three package managers went to council and said in unison
> "We have agreed this specification".
> Are council really going to start picking holes in it and say no?

The council being our global technical lead, I can't see why they
wouldn't be allowed to reject an agreed package manager specification
or parts of it. If not, why bother electing them at all ? Not that I
think that would be a smart move, but that's a different discussion.

Denis.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] A few questions to our nominees

[Richard Freeman]

Denis Dupeyron wrote:
> On Sun, Jun 8, 2008 at 12:45 PM, Roy Bamford <neddyseagoon@gentoo.org> wrote:
>> Before the flames start lets consider the Package Manager Specification
>> (PMS) as an example. For this (very black and white) illustration,
>> forget the council discussions to date and imagine that representatives
>> of all three package managers went to council and said in unison
>> "We have agreed this specification".
>> Are council really going to start picking holes in it and say no?
> 
> The council being our global technical lead, I can't see why they
> wouldn't be allowed to reject an agreed package manager specification
> or parts of it. If not, why bother electing them at all ? Not that I
> think that would be a smart move, but that's a different discussion.
> 

Well, obviously there is a balance here, but one thing that Roy pointed 
out that I completely agree with is the need to have most of the 
discussion BEFORE the meeting.

A council meeting is a very time-limited event which is really designed 
to officially ratify decisions that have essentially already been made. 
  The best place to have open discussion and debate over an issue is on 
mailing lists/etc - this allows the widest possible community to 
participate, and gives people time to consider their decisions.  Policy 
shouldn't be decided by what the best shoot-from-the-hip argument was at 
a 1 hour meeting.

Maybe if an item is on the agenda and it doesn't really have consensus 
there is some value to 5 minutes of free discussion, followed by a delay 
for one month to hash it out on lists/etc.

For the most part I think the current council has embraced this, 
although most of the discussion on lists do not involve council members 
themselves (though they clearly follow the discussions).
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] A few questions to our nominees

[Ciaran McCreesh]

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

On Sun, 08 Jun 2008 07:22:06 -0400
Richard Freeman <rich0@gentoo.org> wrote:
> For the most part I think the current council has embraced this, 
> although most of the discussion on lists do not involve council
> members themselves (though they clearly follow the discussions).

The current council has raised "never actually deciding anything" to an
art form.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] A few questions to our nominees

[Nirbheek Chauhan]

On Sun, Jun 8, 2008 at 4:57 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Sun, 08 Jun 2008 07:22:06 -0400
> Richard Freeman <rich0@gentoo.org> wrote:
>> For the most part I think the current council has embraced this,
>> although most of the discussion on lists do not involve council
>> members themselves (though they clearly follow the discussions).
>
> The current council has raised "never actually deciding anything" to an
> art form.

You have raised "flame and don't actually contribute anything useful"
to an art form.

-- 
~Nirbheek Chauhan
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] A few questions to our nominees

[Ciaran McCreesh]

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

On Sun, 8 Jun 2008 17:05:06 +0530
"Nirbheek Chauhan" <nirbheek.chauhan@gmail.com> wrote:
> > The current council has raised "never actually deciding anything"
> > to an art form.
> 
> You have raised "flame and don't actually contribute anything useful"
> to an art form.

If you seriously think I haven't contributed anything useful, you raise
ignorant nonsensical whining to... well, no, it's still just ignorant
nonsensical whining.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] A few questions to our nominees

[Sergio D. Rodríguez Inclan]

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

Please stay on topic, we don't want another useless flamewar.

-- 
Sergio D. Rodríguez Inclan
-----------------------------------------------------------------------------------------
http://sergio.dicyt-usfx.edu.bo | srinclan @ dicyt-usfx.edu.bo Cel: 79302244
Linux User #446728 --> http://counter.li.org/
Fingerprint: 0C48 829A 40D0 27E7 3B2D D7C3 17A0 A0AF 3291 CFEE
ZeRoX in irc.freenode.org
------------------------------------------------------------------------------------------

[-- Attachment #2: Type: text/html, Size: 686 bytes --]

Re: [gentoo-dev] A few questions to our nominees

[Alex Howells]

2008/6/8 Nirbheek Chauhan <nirbheek.chauhan@gmail.com>:
> You have raised "flame and don't actually contribute anything useful"
> to an art form.

Whilst I'd agree Ciaran flames with the best of them, and trolls with
the worst, you simply cannot contend he never contributed anything to
the project and despite now no longer being a developer, he still
continues to contribute.

I often don't agree with him, but can't help but respect the work he does.

I would like to see Council move towards a more compressed meeting
format -- people presenting arguments need to work out their stuff
before bringing it up in the meeting, and to allow for quick
turn-around of decisions I'd suggest fortnightly meetings which are
time-limited to 60 minutes each.  A prioritized schedule determines
which order we deal with issues in and anything not getting attention
is bumped 2 weeks, with the priority adjusted if necessary to ensure
it gets attention then.

Each issue should be limited to between 5-20 minutes. If people can't
get through the politics and debate in the allotted time then it
should either get bumped 2 weeks and given another 5-20 minutes, or we
should table a special meeting to allow a full 60-90 minutes *just* to
decide that one issue and nothing else.

Sitting around in #gentoo-council for 3-4 hours every month isn't
conducive to progress, it's going to make people get tired/bored and
not pay proper attention and/or not bother to turn up, which just
leads to elections. Endless cycle?
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] A few questions to our nominees

[Nirbheek Chauhan]

n Sun, Jun 8, 2008 at 6:11 PM, Alex Howells <astinus@gentoo.org> wrote:
> 2008/6/8 Nirbheek Chauhan <nirbheek.chauhan@gmail.com>:
>> You have raised "flame and don't actually contribute anything useful"
>> to an art form.
>
> Whilst I'd agree Ciaran flames with the best of them, and trolls with
> the worst, you simply cannot contend he never contributed anything to
> the project and despite now no longer being a developer, he still
> continues to contribute.

I never meant his overall contributions to the project were null. I
meant his usual trend in replying to threads is to flame, and not
contribute anything useful to the THREAD.

>
> I often don't agree with him, but can't help but respect the work he does.
>

*When* he is willing, he can contribute very positively, as is obvious
by the footprints left by him on the Gentoo project. However, this
tendency of his of diverting logical threads towards a gorge by
issuing useless rhetoric and flames is irking me to say the least.

The last few threads are all the evidence anyone needs to verify this.

I do not wish to start a flame war, and will not reply to this thread
concerning this topic anymore.

-- 
~Nirbheek Chauhan
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] A few questions to our nominees

[Peter Weller]

On Sun, 2008-06-08 at 13:41 +0100, Alex Howells wrote:
[snip]
> I often don't agree with him, but can't help but respect the work he does.
> 
> I would like to see Council move towards a more compressed meeting
> format -- people presenting arguments need to work out their stuff
> before bringing it up in the meeting, and to allow for quick
> turn-around of decisions I'd suggest fortnightly meetings which are
> time-limited to 60 minutes each.  A prioritized schedule determines
> which order we deal with issues in and anything not getting attention
> is bumped 2 weeks, with the priority adjusted if necessary to ensure
> it gets attention then.
> 
> Each issue should be limited to between 5-20 minutes. If people can't
> get through the politics and debate in the allotted time then it
> should either get bumped 2 weeks and given another 5-20 minutes, or we
> should table a special meeting to allow a full 60-90 minutes *just* to
> decide that one issue and nothing else.
> 
> Sitting around in #gentoo-council for 3-4 hours every month isn't
> conducive to progress, it's going to make people get tired/bored and
> not pay proper attention and/or not bother to turn up, which just
> leads to elections. Endless cycle?

++ From me on this one. If I were elected to the Council, I would do my
best to get this happening.

welp

-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: A few questions to our nominees

[Tiziano Müller]

Peter Weller wrote:

> On Sun, 2008-06-08 at 13:41 +0100, Alex Howells wrote:
> [snip]
>> I often don't agree with him, but can't help but respect the work he
>> does.
>> 
>> I would like to see Council move towards a more compressed meeting
>> format -- people presenting arguments need to work out their stuff
>> before bringing it up in the meeting, and to allow for quick
>> turn-around of decisions I'd suggest fortnightly meetings which are
>> time-limited to 60 minutes each.  A prioritized schedule determines
>> which order we deal with issues in and anything not getting attention
>> is bumped 2 weeks, with the priority adjusted if necessary to ensure
>> it gets attention then.
>> 
>> Each issue should be limited to between 5-20 minutes. If people can't
>> get through the politics and debate in the allotted time then it
>> should either get bumped 2 weeks and given another 5-20 minutes, or we
>> should table a special meeting to allow a full 60-90 minutes *just* to
>> decide that one issue and nothing else.
>> 
>> Sitting around in #gentoo-council for 3-4 hours every month isn't
>> conducive to progress, it's going to make people get tired/bored and
>> not pay proper attention and/or not bother to turn up, which just
>> leads to elections. Endless cycle?
> 
> ++ From me on this one. If I were elected to the Council, I would do my
> best to get this happening.

++ from me too. Along the lines to what I wrote in gentoo.project.



-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] A few questions to our nominees

[Donnie Berkholz]

On 13:41 Sun 08 Jun     , Alex Howells wrote:
> I would like to see Council move towards a more compressed meeting
> format -- people presenting arguments need to work out their stuff
> before bringing it up in the meeting, and to allow for quick
> turn-around of decisions I'd suggest fortnightly meetings which are
> time-limited to 60 minutes each.  A prioritized schedule determines
> which order we deal with issues in and anything not getting attention
> is bumped 2 weeks, with the priority adjusted if necessary to ensure
> it gets attention then.

I generally attempt to prioritize the agenda, based on urgency (how 
soon, even if minor) rather than importance (critical things that can 
wait). I'm glad to see that you agree with my opinion that biweekly 
meetings could speed up the council's progress.

> Each issue should be limited to between 5-20 minutes. If people can't
> get through the politics and debate in the allotted time then it
> should either get bumped 2 weeks and given another 5-20 minutes, or we
> should table a special meeting to allow a full 60-90 minutes *just* to
> decide that one issue and nothing else.

Yes, this is a good point. I've thought about limiting meetings to 2 
hours as a start (at a once-monthly level, this equates to 1 hour every 
2 weeks). This implies that you also might want to set time limits on 
individual topics so you get to all of them. When combined with 
sufficient preparation, it should work.

I think a key to this is making sure the council members get their 
thoughts on the matters posted (to -dev, -council, whatever) in advance 
of the meeting. That ensures that they've both prepared and hopefully 
hashed out many of the details in advance.

Making meetings shorter should also encourage people to pay more active 
attention so we reduce delays from people working on other things at the 
same time.

> Sitting around in #gentoo-council for 3-4 hours every month isn't
> conducive to progress, it's going to make people get tired/bored and
> not pay proper attention and/or not bother to turn up, which just
> leads to elections. Endless cycle?

I agree. Preparation is something worth requiring. For this month's 
meeting, I suggested last week in #gentoo-council that we simply skip 
topics people haven't prepared for rather than waste seemingly endless 
amounts of time.

Thanks,
Donnie
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] A few questions to our nominees

[Jeroen Roovers]

On Sun, 8 Jun 2008 12:27:52 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> The current council has raised "never actually deciding anything" to
> an art form.

Barking up the wrong (portage) tree again?


Kindest regards,
     JeR
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] A few questions to our nominees

[Luca Barbato]

Piotr Jaroszyński wrote:

> 1. GLEP54
> 2. GLEP55

None of them got discussion back in -dev, the glep hadn't been changed 
as requested during the unnecessary long discussion in the meeting.

Looks like the overall consensus is that those aren't useful as they are 
and thus either you fix them, discussing the changes with the people in 
-dev (NOT THE COUNCIL) or you may retract them.

> 3. Most wanted changes in future EAPIs

Somebody is thinking the PMS and the EAPI definition as it is are wrong 
and should be replaced since they aren't useful for their purpose.

lu

-- 

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

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] A few questions to our nominees

[Piotr Jaroszyński]

2008/6/8 Luca Barbato <lu_zero@gentoo.org>:
> Piotr Jaroszyński wrote:
>
>> 1. GLEP54
>> 2. GLEP55
>
> None of them got discussion back in -dev, the glep hadn't been changed as
> requested during the unnecessary long discussion in the meeting.
>
> Looks like the overall consensus is that those aren't useful as they are and
> thus either you fix them, discussing the changes with the people in -dev
> (NOT THE COUNCIL) or you may retract them.

They don't need any more discussion, but people sitting back and
thinking them through.

>> 3. Most wanted changes in future EAPIs
>
> Somebody is thinking the PMS and the EAPI definition as it is are wrong and
> should be replaced since they aren't useful for their purpose.

Somebody? Replaced with what?

--
Best Regards,
Piotr Jaroszyński

Re: [gentoo-dev] A few questions to our nominees

[Ciaran McCreesh]

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

On Sun, 08 Jun 2008 19:54:46 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> > 3. Most wanted changes in future EAPIs
> 
> Somebody is thinking the PMS and the EAPI definition as it is are
> wrong and should be replaced since they aren't useful for their
> purpose.

Anyone thinking that has a very limited understanding of how things
work. Let's face it, there hasn't been any correct criticism, and any
complaints have been from people who don't understand what's going on
anyway and who seek to blame EAPI for Portage's lack of progress,
rather than blaming Portage's lack of progress for lack of new EAPIs
as they should.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] A few questions to our nominees

[Luca Barbato]

Ciaran McCreesh wrote:
> Anyone thinking that has a very limited understanding of how things
> work.

Usually in this category you put everybody that disagrees with you, no 
matter the topic.

> Let's face it, there hasn't been any correct criticism, and any
> complaints have been from people who don't understand what's going on
> anyway and who seek to blame EAPI for Portage's lack of progress,
> rather than blaming Portage's lack of progress for lack of new EAPIs
> as they should.

I'm afraid you are mixing up emails from this thread. I got complaints 
about how wrongly the PMS is written, e.g. academic paper markup vs 
plain text, natural language used to specify syntax while a grammar 
notation like EBNF would be better suited, when I asked people why so 
few were contributing about this document.

lu

-- 

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

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] A few questions to our nominees

[Ciaran McCreesh]

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

On Mon, 09 Jun 2008 09:58:40 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > Anyone thinking that has a very limited understanding of how things
> > work.
> 
> Usually in this category you put everybody that disagrees with you,
> no matter the topic.

And what does that tell you about the average level of response?

> I'm afraid you are mixing up emails from this thread. I got
> complaints about how wrongly the PMS is written, e.g. academic paper
> markup vs plain text, natural language used to specify syntax while a
> grammar notation like EBNF would be better suited, when I asked
> people why so few were contributing about this document.

Mmm, and how many people claiming that have suggested specific
improvements or pointed out specific complaints? All I've received are
some vague mutterings about how it should be less formal, some vague
mutterings about how it should be more formal, some incoherent rants
about how it's in some way unreadable and no actual specifics. All in
all, something that looks suspiciously like "I don't have any genuine
objections but like to moan"...

So how, specifically, is PMS "wrongly written", and why hasn't anyone
who thinks so bothered to provide details?

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] A few questions to our nominees

[Roy Marples]

On Monday 09 June 2008 09:06:24 Ciaran McCreesh wrote:
> So how, specifically, is PMS "wrongly written", and why hasn't anyone
> who thinks so bothered to provide details?

Probably because you have such a long history of saying "it's broken" without 
providing any details. Even when asked you sometimes choose to ignore the 
question. How does it feel to be on the receiving end for a chance?

Thanks

Roy
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] A few questions to our nominees

[Ciaran McCreesh]

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

On Mon, 9 Jun 2008 09:26:00 +0100
Roy Marples <roy@marples.name> wrote:
> On Monday 09 June 2008 09:06:24 Ciaran McCreesh wrote:
> > So how, specifically, is PMS "wrongly written", and why hasn't
> > anyone who thinks so bothered to provide details?
> 
> Probably because you have such a long history of saying "it's broken"
> without providing any details. Even when asked you sometimes choose
> to ignore the question. How does it feel to be on the receiving end
> for a chance?

No, Roy, no. You're confusing you not understanding the explanation of,
say, exploitable security holes in openrc with you not being told about
them.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] A few questions to our nominees

[Denis Dupeyron]

On Mon, Jun 9, 2008 at 10:06 AM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Mon, 09 Jun 2008 09:58:40 +0200
> Luca Barbato <lu_zero@gentoo.org> wrote:
>> Usually in this category you put everybody that disagrees with you,
>> no matter the topic.
>
> And what does that tell you about the average level of response?

And what does that tell you about how well you fit this community ?

> So how, specifically, is PMS "wrongly written", and why hasn't anyone
> who thinks so bothered to provide details?

See above.

Denis.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] A few questions to our nominees

[Ciaran McCreesh]

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

On Mon, 9 Jun 2008 10:28:57 +0200
"Denis Dupeyron" <calchan@gentoo.org> wrote:
> On Mon, Jun 9, 2008 at 10:06 AM, Ciaran McCreesh
> <ciaran.mccreesh@googlemail.com> wrote:
> > On Mon, 09 Jun 2008 09:58:40 +0200
> > Luca Barbato <lu_zero@gentoo.org> wrote:
> >> Usually in this category you put everybody that disagrees with you,
> >> no matter the topic.
> >
> > And what does that tell you about the average level of response?
> 
> And what does that tell you about how well you fit this community ?

Are you suggesting that Gentoo *should* be a community of people who
don't really know what they're doing who base their work upon things
they half understand that they think they can change without having to
think about the consequences?


-- 
Ciaran McCreesh

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

Re: [gentoo-dev] A few questions to our nominees

[Luca Barbato]

Ciaran McCreesh wrote:
>> I'm afraid you are mixing up emails from this thread. I got
>> complaints about how wrongly the PMS is written, e.g. academic paper
>> markup vs plain text, natural language used to specify syntax while a
>> grammar notation like EBNF would be better suited, when I asked
>> people why so few were contributing about this document.
> 
> Mmm, and how many people claiming that have suggested specific
> improvements or pointed out specific complaints?

You got some right here. Feel free to address them.

> So how, specifically, is PMS "wrongly written", and why hasn't anyone
> who thinks so bothered to provide details?

- rewrite it as an rfc using a markup among xmlrfc, docbook, guidexml.

- use EBNF when describing a syntax.

- split it and version each functional part.

- define EAPI as an aggregate of those versions in a separate part.

lu

-- 

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

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] A few questions to our nominees

[Fernando J. Pereda]

On 9 Jun 2008, at 10:50, Luca Barbato wrote:

> Ciaran McCreesh wrote:
>>> I'm afraid you are mixing up emails from this thread. I got
>>> complaints about how wrongly the PMS is written, e.g. academic paper
>>> markup vs plain text, natural language used to specify syntax  
>>> while a
>>> grammar notation like EBNF would be better suited, when I asked
>>> people why so few were contributing about this document.
>> Mmm, and how many people claiming that have suggested specific
>> improvements or pointed out specific complaints?
>
> You got some right here. Feel free to address them.
>
>> So how, specifically, is PMS "wrongly written", and why hasn't anyone
>> who thinks so bothered to provide details?
>
> - rewrite it as an rfc using a markup among xmlrfc, docbook, guidexml.
>
> - use EBNF when describing a syntax.
>
> - split it and version each functional part.
>
> - define EAPI as an aggregate of those versions in a separate part.
>
> lu

And how specifically is this going to help? You are missing the  
'provide details' part.

- ferdy
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] A few questions to our nominees

[Ciaran McCreesh]

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

On Mon, 09 Jun 2008 10:50:11 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> > So how, specifically, is PMS "wrongly written", and why hasn't
> > anyone who thinks so bothered to provide details?
> 
> - rewrite it as an rfc using a markup among xmlrfc, docbook, guidexml.

What technical reason is there to use a markup that's more work for
those of us doing the writing? Writing XML is a huge pain in the ass
compared to latex.

> - use EBNF when describing a syntax.

Is there any indication that this is any clearer? EBNF gets messy when
it comes to describing the whitespace rules, for example.

> - split it and version each functional part.
> 
> - define EAPI as an aggregate of those versions in a separate part.

From a package manager implementer's perspective, that's a mess. It
means looking all over the place to find relevant information on, say,
what a package dep spec looks like.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] A few questions to our nominees

[Luca Barbato]

Ciaran McCreesh wrote:
> On Mon, 09 Jun 2008 10:50:11 +0200
> Luca Barbato <lu_zero@gentoo.org> wrote:
>>> So how, specifically, is PMS "wrongly written", and why hasn't
>>> anyone who thinks so bothered to provide details?
>> - rewrite it as an rfc using a markup among xmlrfc, docbook, guidexml.
> 
> What technical reason is there to use a markup that's more work for
> those of us doing the writing? Writing XML is a huge pain in the ass
> compared to latex.

More people can understand those markups, they are consistent with the 
gentoo documentation, they look better on screen than on paper, tex is a 
great typesetting markup to write academic books. Right tool for the 
right task. It address the problem "PMS is anything but accessible"

> 
>> - use EBNF when describing a syntax.
> 
> Is there any indication that this is any clearer? EBNF gets messy when
> it comes to describing the whitespace rules, for example.

It is less ambiguous than natural language. That solves the issue "The 
syntax is underspecified"

lu

-- 

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

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] A few questions to our nominees

[Ciaran McCreesh]

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

On Mon, 09 Jun 2008 11:49:35 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:

> Ciaran McCreesh wrote:
> > On Mon, 09 Jun 2008 10:50:11 +0200
> > Luca Barbato <lu_zero@gentoo.org> wrote:
> >>> So how, specifically, is PMS "wrongly written", and why hasn't
> >>> anyone who thinks so bothered to provide details?
> >> - rewrite it as an rfc using a markup among xmlrfc, docbook,
> >> guidexml.
> > 
> > What technical reason is there to use a markup that's more work for
> > those of us doing the writing? Writing XML is a huge pain in the ass
> > compared to latex.
> 
> More people can understand those markups

I've yet to see anyone have any difficulties with Tex.

> they are consistent with the gentoo documentation

GuideXML can't even begin to cover our requirements. Simple example:
try to rewrite the following in GuideXML:

---START---
Global variables must only contain invariant values
(see~\ref{metadata-invariance}). If a global variable's value is
invariant, it may have the value that would be generated at any given
point in the build sequence.

This is demonstrated by code listing~\ref{lst:env-saving}.

\lstinputlisting[float,caption=Environment state between
functions,label=lst:env-saving]{env-saving.listing}
---END---

> they look better on screen than on paper

That's highly questionable. And PMS is sufficiently long that printing
it out is the easiest way of reading it, no matter what format it's in.

> tex is a great typesetting markup to write academic books. Right tool
> for the right task. It address the problem "PMS is anything but
> accessible"

How does making PMS twice the file size and five times as complicated to
edit make it more accessible?

> >> - use EBNF when describing a syntax.
> > 
> > Is there any indication that this is any clearer? EBNF gets messy
> > when it comes to describing the whitespace rules, for example.
> 
> It is less ambiguous than natural language. That solves the issue
> "The syntax is underspecified"

In what places is the syntax currently underspecified, and in said
places, why is EBNF a better solution that tightening up the existing
language? Please illustrate your answer with real examples.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] A few questions to our nominees

[Josh Saddler]

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

Ciaran McCreesh wrote:
> On Mon, 09 Jun 2008 11:49:35 +0200
> Luca Barbato <lu_zero@gentoo.org> wrote:
> 
>> Ciaran McCreesh wrote:
>>> On Mon, 09 Jun 2008 10:50:11 +0200
>>> Luca Barbato <lu_zero@gentoo.org> wrote:
>>>>> So how, specifically, is PMS "wrongly written", and why hasn't
>>>>> anyone who thinks so bothered to provide details?
>>>> - rewrite it as an rfc using a markup among xmlrfc, docbook,
>>>> guidexml.
>>> What technical reason is there to use a markup that's more work for
>>> those of us doing the writing? Writing XML is a huge pain in the ass
>>> compared to latex.
>> More people can understand those markups
> 
> I've yet to see anyone have any difficulties with Tex.
> 
>> they are consistent with the gentoo documentation
> 
> GuideXML can't even begin to cover our requirements. Simple example:
> try to rewrite the following in GuideXML:
> 
> ---START---
> Global variables must only contain invariant values
> (see~\ref{metadata-invariance}). If a global variable's value is
> invariant, it may have the value that would be generated at any given
> point in the build sequence.
> 
> This is demonstrated by code listing~\ref{lst:env-saving}.
> 
> \lstinputlisting[float,caption=Environment state between
> functions,label=lst:env-saving]{env-saving.listing}
> ---END---

Let's change all that hideous, barely readable multiple brace/bracket 
abuse into something more human-readable, shall we?

---

<p>
Global variables must only contain invariant values (see <uri 
link="#metadata-invariance">link</uri>). If a global variable's value is
invariant, it may have the value that would be generated at any given
point in the build sequence.
</p>

<p>
This is demonstrated by the following:
</p>

<pre caption="Environment state between functions" id="env-saving">
bunch o'neat code
</pre>

---

Oh, and that "id" is entirely optional; GuideXML is smart enough to keep 
track of successive code blocks, so you automatically have numerical 
inter/intra document links, as I'll demonstrate at the end of this email.

GuideXML has moved on, while you seem to be stuck in the past. For 
example, look at all the neat things we can do especially for ebuild 
syntax highlighting.[1] Might want to read the rest of that document, 
while you're at it.

Thanks for playing; you lose.


[1] http://www.gentoo.org/doc/en/xml-guide.xml#doc_chap2_sect7


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

Re: [gentoo-dev] A few questions to our nominees

[David Leverton]

On Monday 09 June 2008 11:28:03 Josh Saddler wrote:
> Let's change all that hideous, barely readable multiple brace/bracket
> abuse into something more human-readable, shall we?

Please explain why angle brackets are readable but braces aren't.

> <pre caption="Environment state between functions" id="env-saving">
> bunch o'neat code
> </pre>

Wow, you mean we just type in "bunch o'neat code" and the GuideXML processor 
magically figures out what we want and does it?  That's amazing, you've 
really convinced me!  I'm sure we'll have this checked into the repo in no 
time.

> Thanks for playing; you lose.

LOL
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] A few questions to our nominees

[Ciaran McCreesh]

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

On Mon, 09 Jun 2008 03:28:03 -0700
Josh Saddler <nightmorph@gentoo.org> wrote:
> <p>
> Global variables must only contain invariant values (see <uri 
> link="#metadata-invariance">link</uri>). If a global variable's value
> is invariant, it may have the value that would be generated at any
> given point in the build sequence.
> </p>

First, your link is incorrect. metadata-invariance is in a different
file.

Second, the link's text should be the section name or chapter number.
Rendered as "(see link)" is horribly ugly.

Third, you should have a non-breaking space between 'see' and the
reference.
 
> <p>
> This is demonstrated by the following:
> </p>
> 
> <pre caption="Environment state between functions" id="env-saving">
> bunch o'neat code
> </pre>

How does "bunch o'neat code" deal with our code file containing things
that XML considers to be reserved characters? That code probably has
ampersands and angle brackets in it.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] A few questions to our nominees

[Luca Barbato]

Ciaran McCreesh wrote:
> On Mon, 09 Jun 2008 03:28:03 -0700
> Josh Saddler <nightmorph@gentoo.org> wrote:
>> <p>
>> Global variables must only contain invariant values (see <uri 
>> link="#metadata-invariance">link</uri>). If a global variable's value
>> is invariant, it may have the value that would be generated at any
>> given point in the build sequence.
>> </p>
> 
> First, your link is incorrect. metadata-invariance is in a different
> file.

Pointless nit.

> Second, the link's text should be the section name or chapter number.
> Rendered as "(see link)" is horribly ugly.

your opinion, just yours.

> Third, you should have a non-breaking space between 'see' and the
> reference.

Pointless nit.

> How does "bunch o'neat code" deal with our code file containing things
> that XML considers to be reserved characters? That code probably has
> ampersands and angle brackets in it.

As usual for xml markups.

lu

-- 

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

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] A few questions to our nominees

[Ciaran McCreesh]

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

On Mon, 09 Jun 2008 12:56:33 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > On Mon, 09 Jun 2008 03:28:03 -0700
> > Josh Saddler <nightmorph@gentoo.org> wrote:
> >> <p>
> >> Global variables must only contain invariant values (see <uri 
> >> link="#metadata-invariance">link</uri>). If a global variable's
> >> value is invariant, it may have the value that would be generated
> >> at any given point in the build sequence.
> >> </p>
> > 
> > First, your link is incorrect. metadata-invariance is in a different
> > file.
> 
> Pointless nit.

No, extremely important point. With PMS we can have things split over
lots of files, and not have to care what file something's in when we
link to it. This means we can move things around between files, not
have to worry about breaking links, and be told automatically if we do
screw up a link. How do we get this using GuideXML?

> > Second, the link's text should be the section name or chapter
> > number. Rendered as "(see link)" is horribly ugly.
> 
> your opinion, just yours.

It's really not. Please point me to professional style guides that do
reference links using "link" as the text.

Also see http://www.w3.org/QA/Tips/noClickHere .

> > Third, you should have a non-breaking space between 'see' and the
> > reference.
> 
> Pointless nit.

You're the one that wants good, readable output.

> > How does "bunch o'neat code" deal with our code file containing
> > things that XML considers to be reserved characters? That code
> > probably has ampersands and angle brackets in it.
> 
> As usual for xml markups.

Which is what? You have to manually copy the source content into the
XML document, fixing the code yourself? Or come up with some convoluted
build scripts to do it?

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] A few questions to our nominees

[Fabian Groffen]

On 09-06-2008 11:49:35 +0200, Luca Barbato wrote:
> Ciaran McCreesh wrote:
>> On Mon, 09 Jun 2008 10:50:11 +0200
>> Luca Barbato <lu_zero@gentoo.org> wrote:
>>>> So how, specifically, is PMS "wrongly written", and why hasn't
>>>> anyone who thinks so bothered to provide details?
>>> - rewrite it as an rfc using a markup among xmlrfc, docbook, guidexml.
>>
>> What technical reason is there to use a markup that's more work for
>> those of us doing the writing? Writing XML is a huge pain in the ass
>> compared to latex.
>
> More people can understand those markups, they are consistent with the  
> gentoo documentation, they look better on screen than on paper, tex is a  
> great typesetting markup to write academic books. Right tool for the  
> right task. It address the problem "PMS is anything but accessible"

I think this is a bit of a pointless discussion.  If people insist on
reading the source and are scared of LaTeX, then the same can happen for
any other language.  PMS is available as pdf (or can easily being made
by typing `make`), which is readable IMO, and one could always try how
far one gets with a LaTeX->XML translator and XSLT transformations
afterwards.  Still, what is the point of requiring language X over Y?  I
for one prefer LaTeX over any of the formats you mentioned before, but
that should not be of any value here.

>>> - use EBNF when describing a syntax.
>>
>> Is there any indication that this is any clearer? EBNF gets messy when
>> it comes to describing the whitespace rules, for example.
>
> It is less ambiguous than natural language. That solves the issue "The  
> syntax is underspecified"

Perhaps some examples showing the syntax could improve the situation here?


-- 
Fabian Groffen
Gentoo on a different level
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] A few questions to our nominees

[Thomas Anderson]

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

On Mon, Jun 09, 2008 at 01:00:52PM +0200, Fabian Groffen wrote:
> On 09-06-2008 11:49:35 +0200, Luca Barbato wrote:
> > Ciaran McCreesh wrote:
> >> On Mon, 09 Jun 2008 10:50:11 +0200
> >> Luca Barbato <lu_zero@gentoo.org> wrote:
> >>>> So how, specifically, is PMS "wrongly written", and why hasn't
> >>>> anyone who thinks so bothered to provide details?
> >>> - rewrite it as an rfc using a markup among xmlrfc, docbook, guidexml.
> >>
> >> What technical reason is there to use a markup that's more work for
> >> those of us doing the writing? Writing XML is a huge pain in the ass
> >> compared to latex.
> >
> > More people can understand those markups, they are consistent with the  
> > gentoo documentation, they look better on screen than on paper, tex is a  
> > great typesetting markup to write academic books. Right tool for the  
> > right task. It address the problem "PMS is anything but accessible"
> 
> I think this is a bit of a pointless discussion.  If people insist on
> reading the source and are scared of LaTeX, then the same can happen for
> any other language.  PMS is available as pdf (or can easily being made
> by typing `make`), which is readable IMO, and one could always try how
> far one gets with a LaTeX->XML translator and XSLT transformations
> afterwards.  Still, what is the point of requiring language X over Y?  I
> for one prefer LaTeX over any of the formats you mentioned before, but
> that should not be of any value here.

++

I personally have had no problems reading and/or understanding PMS, and
I've had to reference a fair bit of it. I'd like to hear exactly who has
problems with what sections and how to fix that. 

As Fabian said it really isn't a matter of "We like XML better than LaTeX!" It's not those people's
perogative. The people who wrote PMS should be able to make the decision
for themselves(as they will be maintaining it) as to what language to
use. If they use LaTeX, more power to them, it's what enables them to do
their job in the easiest way. You don't *have* to read PMS in LaTeX,
which by the way makes my eyes bleed somewhat, you can read it in a very
well done PDF.

Regards,
Thomas

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

Re: [gentoo-dev] A few questions to our nominees

[Luca Barbato]

Thomas Anderson wrote:
> As Fabian said it really isn't a matter of "We like XML better than LaTeX!"
> It's not those people's prerogative.

Problems like having homogeneous documentation aren't that small.

> The people who wrote PMS should be able to make the decision
> for themselves(as they will be maintaining it) as to what language to
> use.

The main point being using latex prevents people from modify it.

> If they use LaTeX, more power to them, it's what enables them to do
> their job in the easiest way.

Depends on what the job is.

> You don't *have* to read PMS in LaTeX,
> which by the way makes my eyes bleed somewhat, you can read it in a very
> well done PDF.

The pdf renders poorly on xpdf due the fonts latex has, usually I'd 
rather have plain text anyway.

lu

-- 

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

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] A few questions to our nominees

[Fernando J. Pereda]

On 9 Jun 2008, at 14:18, Luca Barbato wrote:
>> The people who wrote PMS should be able to make the decision
>> for themselves(as they will be maintaining it) as to what language to
>> use.
>
> The main point being using latex prevents people from modify it.

Your opinion.

>> You don't *have* to read PMS in LaTeX,
>> which by the way makes my eyes bleed somewhat, you can read it in a  
>> very
>> well done PDF.
>
> The pdf renders poorly on xpdf due the fonts latex has, usually I'd  
> rather have plain text anyway.

Pointless nit.

- ferdy
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] A few questions to our nominees

[Ciaran McCreesh]

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

On Mon, 09 Jun 2008 14:18:01 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> > The people who wrote PMS should be able to make the decision
> > for themselves(as they will be maintaining it) as to what language
> > to use.
> 
> The main point being using latex prevents people from modify it.

Are you seriously suggesting that hypothetical contributions we might
receive from people who hypothetically might contribute if only we used
XML instead of Latex outweigh all the extra work XML requires?

> > You don't *have* to read PMS in LaTeX,
> > which by the way makes my eyes bleed somewhat, you can read it in a
> > very well done PDF.
> 
> The pdf renders poorly on xpdf due the fonts latex has, usually I'd 
> rather have plain text anyway.

The PDF spec requires that PDF readers have certain fonts available,
and those're the fonts we're using.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] A few questions to our nominees

[Thomas Anderson]

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

On Mon, Jun 09, 2008 at 01:26:53PM +0100, Ciaran McCreesh wrote:
> On Mon, 09 Jun 2008 14:18:01 +0200
> Luca Barbato <lu_zero@gentoo.org> wrote:
> > > The people who wrote PMS should be able to make the decision
> > > for themselves(as they will be maintaining it) as to what language
> > > to use.
> > 
> > The main point being using latex prevents people from modify it.
> 
> Are you seriously suggesting that hypothetical contributions we might
> receive from people who hypothetically might contribute if only we used
> XML instead of Latex outweigh all the extra work XML requires?

Right, and though I don't understand LaTeX all that well, it wasn't too
difficult to stop me from writing the spec for one function. I
personally dislike XML even more than LaTeX, but that shouldn't stop
those who wrote it from using it.

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

Re: [gentoo-dev] A few questions to our nominees

[Matthias Langer]

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


On Mon, 2008-06-09 at 14:18 +0200, Luca Barbato wrote:
> Thomas Anderson wrote:
> > As Fabian said it really isn't a matter of "We like XML better than LaTeX!"
> > It's not those people's prerogative.
> 
> Problems like having homogeneous documentation aren't that small.
> 
> > The people who wrote PMS should be able to make the decision
> > for themselves(as they will be maintaining it) as to what language to
> > use.
> 
> The main point being using latex prevents people from modify it.
> 

Untrue... latex is documented, and lots of people feel more comfortable
with it than with XML (for example me). It's just a matter of taste and
thus a decision of the people actually doing the work.
 
> > If they use LaTeX, more power to them, it's what enables them to do
> > their job in the easiest way.
> 
> Depends on what the job is.
> 
> > You don't *have* to read PMS in LaTeX,
> > which by the way makes my eyes bleed somewhat, you can read it in a very
> > well done PDF.
> 
> The pdf renders poorly on xpdf due the fonts latex has, usually I'd 
> rather have plain text anyway.
> 

Install app-text/evince. It looks quite nice there.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] A few questions to our nominees

[Jan Kundrát]

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

Luca Barbato wrote:
> Thomas Anderson wrote:
>> As Fabian said it really isn't a matter of "We like XML better than 
>> LaTeX!"
>> It's not those people's prerogative.
> 
> Problems like having homogeneous documentation aren't that small.

See the devmanual. It uses completely different XML markup. It is XML, 
but not compatible at all with the GuideXML.

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth


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

Re: [gentoo-dev] A few questions to our nominees

[Jan Kundrát]

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

Thomas Anderson wrote:
> I personally have had no problems reading and/or understanding PMS, and
> I've had to reference a fair bit of it. I'd like to hear exactly who has
> problems with what sections and how to fix that. 
> 
> As Fabian said it really isn't a matter of "We like XML better than LaTeX!" It's not those people's
> perogative. The people who wrote PMS should be able to make the decision
> for themselves(as they will be maintaining it) as to what language to
> use. If they use LaTeX, more power to them, it's what enables them to do
> their job in the easiest way. You don't *have* to read PMS in LaTeX,
> which by the way makes my eyes bleed somewhat, you can read it in a very
> well done PDF.

For those that don't know me, I'm a member of the Documentation Team. I 
also have some background with XSLT (not as huge as neysx, our leader, 
has, but still I'm not really a begginer in this area).

That said, I completely agree with the choice of latex in this 
particular case. If there was a fixed request on GudeXML, this document 
would not have been at all written yet.

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth


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

[gentoo-dev] Re: A few questions to our nominees

[Tiziano Müller]

Luca Barbato wrote:

> Ciaran McCreesh wrote:
>>> I'm afraid you are mixing up emails from this thread. I got
>>> complaints about how wrongly the PMS is written, e.g. academic paper
>>> markup vs plain text, natural language used to specify syntax while a
>>> grammar notation like EBNF would be better suited, when I asked
>>> people why so few were contributing about this document.
>> 
>> Mmm, and how many people claiming that have suggested specific
>> improvements or pointed out specific complaints?
> 
> You got some right here. Feel free to address them.
> 
>> So how, specifically, is PMS "wrongly written", and why hasn't anyone
>> who thinks so bothered to provide details?
> 
> - rewrite it as an rfc using a markup among xmlrfc, docbook, guidexml.
... add DITA to the list.

Sorry, but I think it is not fair to make such requests AFTER the document
is written. That should've been done when the work started and the council
should have made the decision that only a PMS written using GuideXML (or
whatever) will be accepted. Lack of specification is not the failure of the
ones who did the work.


-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: A few questions to our nominees

[Tiziano Müller]

Piotr Jaroszy?ski wrote:

> Hello,
> 
> looks like every nominee wants the council to be more technical so I
> have a few technical questions for you:
> 
> 1. GLEP54
Doit!

> 2. GLEP55
Good idea. But the GLEP still contains too many "may"'s and "should"'s.
Example: "[...] but note that one should never explicitly set both EAPIs to
different values. [...]". Define it clearer: "It is not allowed to set both
EAPIs.".

And why don't we change the versioning of the EAPI to a "X.Y" scheme and
demand that changes in the minor version must not break sourcing of the
ebuild with older package managers and that major versions do.
Major version numbers are written in the postfix, while minor version
numbers are written in the ebuild itself as EAPI_MINOR="1". So, the current
EAPI 1 would then be in fact "0.1".

Cheers,
Tiziano


-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: A few questions to our nominees

[Ciaran McCreesh]

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

On Mon, 09 Jun 2008 09:45:37 +0200
Tiziano Müller <dev-zero@gentoo.org> wrote:
> And why don't we change the versioning of the EAPI to a "X.Y" scheme
> and demand that changes in the minor version must not break sourcing
> of the ebuild with older package managers and that major versions do.
> Major version numbers are written in the postfix, while minor version
> numbers are written in the ebuild itself as EAPI_MINOR="1". So, the
> current EAPI 1 would then be in fact "0.1".

No point. A 0 package manager still couldn't use a 0.1 ebuild.

-- 
Ciaran McCreesh

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

[gentoo-dev] Re: Re: A few questions to our nominees

[Tiziano Müller]

Ciaran McCreesh wrote:

> On Mon, 09 Jun 2008 09:45:37 +0200
> Tiziano Müller <dev-zero@gentoo.org> wrote:
>> And why don't we change the versioning of the EAPI to a "X.Y" scheme
>> and demand that changes in the minor version must not break sourcing
>> of the ebuild with older package managers and that major versions do.
>> Major version numbers are written in the postfix, while minor version
>> numbers are written in the ebuild itself as EAPI_MINOR="1". So, the
>> current EAPI 1 would then be in fact "0.1".
> 
> No point. A 0 package manager still couldn't use a 0.1 ebuild.
> 
That's true, it has at least to be aware the there's an EAPI.
But how does such a package manager handle .ebuild-0 files? Ignore them?
Failing because of unknown files in a package-dir?
Should we care about package managers not being aware of the existence of
EAPI's?

The advantage of the above would be that we could gradually implement new
(not-breaking-sourcing) features incrementing the minor version. Avoiding
big chunks of changes (which usually means greater risk).


-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Re: A few questions to our nominees

[Ciaran McCreesh]

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

On Mon, 09 Jun 2008 10:27:56 +0200
Tiziano Müller <dev-zero@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > No point. A 0 package manager still couldn't use a 0.1 ebuild.
> > 
> That's true, it has at least to be aware the there's an EAPI.
> But how does such a package manager handle .ebuild-0 files? Ignore
> them? Failing because of unknown files in a package-dir?
> Should we care about package managers not being aware of the
> existence of EAPI's?

Package managers can't do *anything* with ebuilds with unsupported
EAPIs anyway. Encouraging package managers to handle ebuilds with
unsupported EAPIs in any way just massively limits what can be done in
future EAPIs.

-- 
Ciaran McCreesh

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

[gentoo-dev] Re: Re: Re: A few questions to our nominees

[Tiziano Müller]

Ciaran McCreesh wrote:

> On Mon, 09 Jun 2008 10:27:56 +0200
> Tiziano Müller <dev-zero@gentoo.org> wrote:
>> Ciaran McCreesh wrote:
>> > No point. A 0 package manager still couldn't use a 0.1 ebuild.
>> > 
>> That's true, it has at least to be aware the there's an EAPI.
>> But how does such a package manager handle .ebuild-0 files? Ignore
>> them? Failing because of unknown files in a package-dir?
>> Should we care about package managers not being aware of the
>> existence of EAPI's?
> 
> Package managers can't do *anything* with ebuilds with unsupported
> EAPIs anyway. Encouraging package managers to handle ebuilds with
> unsupported EAPIs in any way just massively limits what can be done in
> future EAPIs.
> 
Em, that's really not what I meant. The main problem GLEP 55 describes is
that with the current system we're limited to changes which don't break
sourcing the ebuild (since if it would break sourcing we couldn't even find
out the ebuild's EAPI version and therefore not whether the currently used
package manager can handle that ebuild).
That package managers can't do anything else than masking ebuilds with
unsupported EAPIs is clear.
But what I wanted to say is:
Having the EAPI versioned like this: X.Y where X is the postfix part of the
ebuild (foo-1.0.ebuild-X) and Y the "EAPI=Y" in the ebuild itself we could
increment Y in case the changes to the EAPI don't break sourcing (again: a
package manager will have to mask those ebuilds) while changes breaking the
sourcing of the ebuild need an increment of X to avoid that pm's not being
able to even source such an ebuild still can mask it properly (or just
ignore it).


-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: A few questions to our nominees

[Jan Kundrát]

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

Tiziano Müller wrote:
> Having the EAPI versioned like this: X.Y where X is the postfix part of the
> ebuild (foo-1.0.ebuild-X) and Y the "EAPI=Y" in the ebuild itself we could
> increment Y in case the changes to the EAPI don't break sourcing (again: a
> package manager will have to mask those ebuilds) while changes breaking the
> sourcing of the ebuild need an increment of X to avoid that pm's not being
> able to even source such an ebuild still can mask it properly (or just
> ignore it).

What benefits would that offer?

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth


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

[gentoo-dev] Re: Re: Re: Re: A few questions to our nominees

[Tiziano Müller]

Jan Kundrát wrote:

> Tiziano Müller wrote:
>> Having the EAPI versioned like this: X.Y where X is the postfix part of
>> the ebuild (foo-1.0.ebuild-X) and Y the "EAPI=Y" in the ebuild itself we
>> could increment Y in case the changes to the EAPI don't break sourcing
>> (again: a package manager will have to mask those ebuilds) while changes
>> breaking the sourcing of the ebuild need an increment of X to avoid that
>> pm's not being able to even source such an ebuild still can mask it
>> properly (or just ignore it).
> 
> What benefits would that offer?

This depends on how we want to "drive" our development process.
The scheme I described would allow us to make many small improvements (given
they don't break sourcing of the builds) while the sole postfix-versioning
of the EAPI seems to be a model with less big changes.


-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: A few questions to our nominees

[Piotr Jaroszyński]

2008/6/9 Tiziano Müller <dev-zero@gentoo.org>:
> Ciaran McCreesh wrote:
>
>> On Mon, 09 Jun 2008 10:27:56 +0200
>> Tiziano Müller <dev-zero@gentoo.org> wrote:
>>> Ciaran McCreesh wrote:
>>> > No point. A 0 package manager still couldn't use a 0.1 ebuild.
>>> >
>>> That's true, it has at least to be aware the there's an EAPI.
>>> But how does such a package manager handle .ebuild-0 files? Ignore
>>> them? Failing because of unknown files in a package-dir?
>>> Should we care about package managers not being aware of the
>>> existence of EAPI's?
>>
>> Package managers can't do *anything* with ebuilds with unsupported
>> EAPIs anyway. Encouraging package managers to handle ebuilds with
>> unsupported EAPIs in any way just massively limits what can be done in
>> future EAPIs.
>>
> Em, that's really not what I meant. The main problem GLEP 55 describes is
> that with the current system we're limited to changes which don't break
> sourcing the ebuild (since if it would break sourcing we couldn't even find
> out the ebuild's EAPI version and therefore not whether the currently used
> package manager can handle that ebuild).
> That package managers can't do anything else than masking ebuilds with
> unsupported EAPIs is clear.
> But what I wanted to say is:
> Having the EAPI versioned like this: X.Y where X is the postfix part of the
> ebuild (foo-1.0.ebuild-X) and Y the "EAPI=Y" in the ebuild itself we could
> increment Y in case the changes to the EAPI don't break sourcing (again: a
> package manager will have to mask those ebuilds) while changes breaking the
> sourcing of the ebuild need an increment of X to avoid that pm's not being
> able to even source such an ebuild still can mask it properly (or just
> ignore it).

What's the point of sourcing an ebuild that cannot be used anyway?

-- 
Best Regards,
Piotr Jaroszyński

[gentoo-dev] Re: A few questions to our nominees

[Duncan]

"=?UTF-8?Q?Piotr_Jaroszy=C5=84ski?=" <peper@gentoo.org> posted
d77765540806091313i4c7f273fq2cbaaaac0654ac5a@mail.gmail.com, excerpted
below, on  Mon, 09 Jun 2008 22:13:20 +0200:

> What's the point of sourcing an ebuild that cannot be used anyway?

As currently seen in portage at least... a PM can be aware of and source 
an EAPI it can't use, but with the sourcing, can at least print a message 
to the effect "You must have a PM that supports EAPI-X in ordered to 
merge this package."

If the ebuild can't be sourced, then ignoring it altogether is the safest 
alternative -- and what portage would do with anything other 
than .ebuild.  It can't print a message giving the EAPI that must be 
supported, because it can't get that info, it being in the content that 
can't be sourced.

With major-suffix minor-source, once the major-suffix rules were laid 
out, it would be possible to print support messages for minor (within the 
same major), as we do now, and provided the suffix rules were specific 
enough, for cross-major (only) as well, but not cross-major minor.

IOW, the PM could print EAPI minor-1 (major being zero) messages as 
portage does now, and be made to print major-1 messages, but since it 
couldn't source, it couldn't get to the detail of major-1.minor-x, except 
after upgrade to a version that handled major-1, after which minor-x 
would either be supported or a new message could be printed prompting 
further upgrade/sidegrade/downgrade within the major support, to support 
the correct minor, as the case may be.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Re: A few questions to our nominees

[Piotr Jaroszyński]

> That's true, it has at least to be aware the there's an EAPI.
> But how does such a package manager handle .ebuild-0 files? Ignore them?
> Failing because of unknown files in a package-dir?
> Should we care about package managers not being aware of the existence of
> EAPI's?

Current portage would simply ignore them, which allows to use them
right away in the tree (we would only need to make sure that
developers touching packages using new format have up to date tools).
Future portage would handle them nicely w/o the risk of dying when
trying to figure out ebuild's EAPI, which is the point here.

-- 
Best Regards,
Piotr Jaroszyński

Re: [gentoo-dev] Re: Re: A few questions to our nominees

[Peter Weller]

[..snip..]

This doesn't, to me, really seem to be relevant to the original purpose
of the thread. Can we either start a new thread or get this one back on
topic?

welp

-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: Re: Re: A few questions to our nominees

[Tiziano Müller]

Peter Weller wrote:

> [..snip..]
> 
> This doesn't, to me, really seem to be relevant to the original purpose
> of the thread. Can we either start a new thread or get this one back on
> topic?
In the context of whether this GLEP is complete and should be approved it
does make sense. It is important to know whether introducing such a change
breaks current apps or not.
peper: Can you please add this as a compatibility note to the GLEP?


-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] A few questions to our nominees

[Donnie Berkholz]

On 11:12 Sun 08 Jun     , Piotr Jaroszyński wrote:
> Hello,
> 
> looks like every nominee wants the council to be more technical so I
> have a few technical questions for you:
> 
> 1. GLEP54
> 2. GLEP55

I don't have any particular objections to these, besides the vague 
aesthetic one of having EAPI in the filename. Particularly long, weird 
EAPIs filled with special characters (to which some will reply "So don't 
do that").

It would be pretty cool to be able to sync a portage tree excluding 
ebuilds of any unsupported EAPI, though.

> 3. Most wanted changes in future EAPIs

USE deps (in portage as of $recent, so we might be able to do this soon)

Anything that's gotten to the point where people hack around it to use 
it in the tree is clearly something that should become part of an EAPI, 
a la built_with_use(). That's one kind of action that shows something is 
a feature we really need.


Some features I'd like to see in general use that may not require new 
EAPIs:

  -New eclasses and elibs (GLEP 33)
  -Clean multilib support (PM treating ABI to allow multiples of the 
   same PVR)
  -USE flag groups (GLEP 29) that don't suck like USE_EXPAND
  -Signing everything (eclasses and all)
  -GLEP 42 (news reporting) finally getting used

Other things I'd like to see:

  -A hosting site for all of our patches. This would enable better 
   collaboration with other distros and upstream.
  -More unit tests, building on the ones I posted to -dev recently.
  -A real tinderbox server doing continuous integration tests that 
   people can check at any time and that will do the blame game and 
   email people who broke something.
  -Someone to finish creandus (pioto's user creation thingy)


Thanks,
Donnie
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] A few questions to our nominees

[Joe Peterson]

Donnie Berkholz wrote:
> On 11:12 Sun 08 Jun     , Piotr Jaroszyński wrote:
>> looks like every nominee wants the council to be more technical so I
>> have a few technical questions for you:
>>
>> 1. GLEP54
>> 2. GLEP55
> 
> I don't have any particular objections to these, besides the vague 
> aesthetic one of having EAPI in the filename. Particularly long, weird 
> EAPIs filled with special characters (to which some will reply "So don't 
> do that").

Donnie, I agree, and I think it would be a mistake to use the filename
extension for the EAPI number, even for simple "non-long-or-funky"
EAPIs.  I know that my reasons will be considered, by some, to be
irrelevant (especially since aesthetics and/or style/elegance are of less
importance to some), but I really think this should be carefully considered;
a mistake here would be quite a shame.  I'll state again (slightly modified)
what I wrote a while back on this issue.

Technical reasons to avoid the filename:

1) Increase of [needless] complexity in filenames/extensions (and only one
   example of the impact is that searching for ebuild files becomes less
   straightforward), when things like SLOT, EAPI, etc., etc., seem to
   naturally belong as part of the script contents/syntax.
2) Having the same info in more than one place is generally a bad idea in
   any design - this is true in any discipline.  I don't care how many people
   say a) that this is not an issue or b) that it's "not a duplication",
   in every data system I've worked on, it has been a very bad idea to have
   more than one version of the same info that can get out of sync with each
   other.  Even if you take great care, I'd still always want to check both
   and not trust either version of the info blindly.  Caching or hashing is
   different (i.e. where the caching mechanism is robust), since the
   system itself keeps the cache up to date, and one version of the info
   is strictly derived from the other rather than both being the source.
3) It uses the extension in a way that goes against common use in computers,
   especially *nix.  No longer could we then say that a file of type
   "Gentoo ebuild" has the extension "ebuild"
   (simple/straightforward/standard).
4) It seems that the motivation for this GLEP is so that the tools can
   determine the EAPI without reading/sourcing the script.  In order to
   get around this, the GLEP suggests exposing this technical information
   in the filename.  This is the wrong place to expose it, and the reasons
   given are not that this detail should be exposed there but rather because
   it is inefficient to source the file to get the info.  So this is a case
   of trying to solve a technical issue by changing the interface.  I
   believe it would be more correct to attack the technical problem in a way
   that does not do this, and I am sure this can be solved.

Other reasons:

1) Littering the filename with this kind of stuff is potentially confusing to
   both devs and users - I know it's been stated that users shouldn't care,
   but I don't think that's a good reason/assumption.
2) It is not an elegant filename policy.  Many systems have elegance as
   a design goal.
3) Assuming going this route is a mistake, it could be hard to reverse.

Currently, I consider Gentoo's ebuild filename conventions simple and
elegant.  In fact, it is beautifully done.  I'd hate to see this go down the
wrong path now.

						-Joe

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] A few questions to our nominees

[pioto]

On Mon, 9 Jun 2008, Joe Peterson wrote:

> Technical reasons to avoid the filename:
>
> 1) Increase of [needless] complexity in filenames/extensions (and only one
>   example of the impact is that searching for ebuild files becomes less
>   straightforward), when things like SLOT, EAPI, etc., etc., seem to
>   naturally belong as part of the script contents/syntax.

Okay... so:
   find /usr/portage -name *ebuild

becomes:
   find /usr/portage -name *ebuild*

That doesn't seem that much harder to me... Same for the file detection 
for editors.

> 2) Having the same info in more than one place is generally a bad idea in
>   any design - this is true in any discipline. [...]

If you read the proposal more closely, you would notice that it 
specifically says to *not* specify EAPI in more than one place. It belongs 
solely in the filename suffix. The only reason the EAPI variable would be 
recognized inside the file itself is to allow for backwards compatibility 
with the current way EAPI=1 is done -- this behavior would be discouraged 
in all future ebuilds.

> 3) It uses the extension in a way that goes against common use in computers,
>   especially *nix.  No longer could we then say that a file of type
>   "Gentoo ebuild" has the extension "ebuild"
>   (simple/straightforward/standard).

In most unixes, the file extension is completely meaningless. What matters 
is the contents of the file. Nautilus, etc, mostly use detection based 
upon the files contents to identify file types (at least for local files), 
not file extensoins.

> 4) It seems that the motivation for this GLEP is so that the tools can
>   determine the EAPI without reading/sourcing the script.  In order to
>   get around this, the GLEP suggests exposing this technical information
>   in the filename.  This is the wrong place to expose it, and the reasons
>   given are not that this detail should be exposed there but rather because
>   it is inefficient to source the file to get the info.  So this is a case
>   of trying to solve a technical issue by changing the interface.  I
>   believe it would be more correct to attack the technical problem in a way
>   that does not do this, and I am sure this can be solved.

The reason for this is that, while the current two EAPIs don't cause 
trouble if you try to source them when you don't support them, that 
doesn't mean future ones won't. I'm not talking about anything silly like 
rewriting ebuilds in python, but things like changing syntax for DEPEND 
could potentially confuse older package managers. By adding the EAPI 
specification to the filename instead, old package managers just plain 
won't see packages they don't understand, so there's no need to worry 
about this.

Also, sourcing a package to extract one metadata key takes much more time 
than just not loading it in the first place.

> Other reasons:
>
> 1) Littering the filename with this kind of stuff is potentially confusing to
>   both devs and users - I know it's been stated that users shouldn't care,
>   but I don't think that's a good reason/assumption.

New eapis aren't necessarily of any immediate use to people. Those who 
don't see the need for them can continue to just use EAPI=0, plain old 
.ebuild files of the sort that've been around for years, and for many 
packages this is totally appropriate. The only devs who should care are 
the ones who have a need for the new features.

Users shouldn't ever have to read the ebuild files themselves. The package 
manager should tell them everything they need to know.

> 2) It is not an elegant filename policy.  Many systems have elegance as
>   a design goal.

That's a matter of opinion. It seems perfectly elegant to me -- not to 
mention the various, rather clear technical benefits of it.

> 3) Assuming going this route is a mistake, it could be hard to reverse.

Not really. The entire point of this scheme is that we can change at any 
time w/o breaking stuff. If we decide to go with .pbuild files for the 
future, we can just do that. Old package managers still won't care.

-- 
Mike Kelly
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] GLEP 55 (was: A few questions to our nominees)

[Joe Peterson]

pioto@pioto.org wrote:
>> 1) Increase of [needless] complexity in filenames/extensions (and only one
>>   example of the impact is that searching for ebuild files becomes less
>>   straightforward), when things like SLOT, EAPI, etc., etc., seem to
>>   naturally belong as part of the script contents/syntax.
> 
> Okay... so:
>    find /usr/portage -name *ebuild
> 
> becomes:
>    find /usr/portage -name *ebuild*
> 
> That doesn't seem that much harder to me... Same for the file detection 
> for editors.

I'm not saying it's a lot harder.  But it is more complex and less
elegant.  Also, it is error-prone.  If someone, by habit, looks for all
"*.ebuild", he will miss a portion of the ebuilds and not even realize
it at first (or ever).

>> 2) Having the same info in more than one place is generally a bad idea in
>>   any design - this is true in any discipline. [...]
> 
> If you read the proposal more closely, you would notice that it 
> specifically says to *not* specify EAPI in more than one place. It belongs 
> solely in the filename suffix. The only reason the EAPI variable would be 
> recognized inside the file itself is to allow for backwards compatibility 
> with the current way EAPI=1 is done -- this behavior would be discouraged 
> in all future ebuilds.

Still, the GLEP addresses the very point of what logic has to be
followed if the EAPI exists in the filename, in the file, or both.  It
talks of "pre-source" EAPIs and "post-source" EAPIs.  Complicated.

>> 3) It uses the extension in a way that goes against common use in computers,
>>   especially *nix.  No longer could we then say that a file of type
>>   "Gentoo ebuild" has the extension "ebuild"
>>   (simple/straightforward/standard).
> 
> In most unixes, the file extension is completely meaningless. What matters 
> is the contents of the file. Nautilus, etc, mostly use detection based 
> upon the files contents to identify file types (at least for local files), 
> not file extensoins.

That wasn't the point I was trying to make.  I am not saying that the
extension has special meaning (even the "." has no meaning, really, in
unix) to software.  I mean that people associate certain types of files
with certain extensions.  I'm speaking more of the human interface here.

>> 4) It seems that the motivation for this GLEP is so that the tools can
>>   determine the EAPI without reading/sourcing the script.  In order to
>>   get around this, the GLEP suggests exposing this technical information
>>   in the filename.  This is the wrong place to expose it, and the reasons
>>   given are not that this detail should be exposed there but rather because
>>   it is inefficient to source the file to get the info.  So this is a case
>>   of trying to solve a technical issue by changing the interface.  I
>>   believe it would be more correct to attack the technical problem in a way
>>   that does not do this, and I am sure this can be solved.
> 
> The reason for this is that, while the current two EAPIs don't cause 
> trouble if you try to source them when you don't support them, that 
> doesn't mean future ones won't. I'm not talking about anything silly like 
> rewriting ebuilds in python, but things like changing syntax for DEPEND 
> could potentially confuse older package managers. By adding the EAPI 
> specification to the filename instead, old package managers just plain 
> won't see packages they don't understand, so there's no need to worry 
> about this.

Well, in general, if you rely on extensions changing every time a
program cannot deal with a new feature of a file format, it would be
quite crazy.  For example, if C programs had to start using ".c-2",
".c-3", etc., it would get ugly fast.  Also, it is easy to build EAPI
checking into portage now, and when the requisite time passes, you only
need to deal with situations where *very* old portage versions are still
in use.  Since portage is typically the first thing the system upgrades
after a sync, I don't see a big issue.  Or, if that is not acceptable,
see my comment at the end about a one-time change to a new extension
like ".eb".

> Also, sourcing a package to extract one metadata key takes much more time 
> than just not loading it in the first place.

I understand there are technical/performance issues to solve, but this
does not, IMHO, justify moving this info into a filename/extension.

>> 1) Littering the filename with this kind of stuff is potentially confusing to
>>   both devs and users - I know it's been stated that users shouldn't care,
>>   but I don't think that's a good reason/assumption.
> 
> New eapis aren't necessarily of any immediate use to people. Those who 
> don't see the need for them can continue to just use EAPI=0, plain old 
> .ebuild files of the sort that've been around for years, and for many 
> packages this is totally appropriate. The only devs who should care are 
> the ones who have a need for the new features.

But when they do need the new features, they need to use the new EAPIs.
 This is not a matter of "degree" - it is a matter of defining the
filename format.  Once you allow freeform ".ebuild-????" extensions,
everyone has to deal with the possibility of their existence.

> Users shouldn't ever have to read the ebuild files themselves. The package 
> manager should tell them everything they need to know.

It doesn't matter, users still will look at the builds and the
directories they are in.  And I am sure many users do this regularly.
We are not hiding the details of the files and filenames in an opaque
database where none of this would matter (we're not MicroSoft, after all
:).  What Gentoo proudly calls the main portage tree is out there for
all to see and examine, which is a good thing.

But what users *really* don't care about is EAPIs, and this GLEP would
expose that technical detail to them in a very blatent way.

Everything else in the filename is something portage exposes to them in
its interface (category, package, version, revision, etc.), so this
would be the first thing in the filename that would *not* match up with
something we want to expose to users.  EAPI is really something that
should be under the hood.

>> 2) It is not an elegant filename policy.  Many systems have elegance as
>>   a design goal.
> 
> That's a matter of opinion. It seems perfectly elegant to me -- not to 
> mention the various, rather clear technical benefits of it.

Yes, it is a matter of opinion, and I feel GLEP 55 would do things in a
very non-standard and confusing way, for users and for devs.

The fact that it makes the technical solution particularly easy (or an
easy short-cut) is not a justification.

>> 3) Assuming going this route is a mistake, it could be hard to reverse.
> 
> Not really. The entire point of this scheme is that we can change at any 
> time w/o breaking stuff. If we decide to go with .pbuild files for the 
> future, we can just do that. Old package managers still won't care.

Along those lines, as I've said before, migrating to a new extension,
*one-time*, as a solution to this, although not optimal, would be far
more satisfactory than introducing a series of ever-changing extensions.

For example,
http://en.wikipedia.org/wiki/Alphabetical_list_of_file_extensions#E does
not list ".eb", so gentoo could adopt that one, slowly phasing out
".ebuild" over time.  At least this would signify that it is an ".eb"
(ebuild) file, not that it is an ".ebuild-4", which happens to be a type
of ebuild file that requires version 4 of EAPI.

					-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] GLEP 55 (was: A few questions to our nominees)

[Ciaran McCreesh]

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

On Mon, 09 Jun 2008 19:49:08 -0600
Joe Peterson <lavajoe@gentoo.org> wrote:
> I'm not saying it's a lot harder.  But it is more complex and less
> elegant.  Also, it is error-prone.  If someone, by habit, looks for
> all "*.ebuild", he will miss a portion of the ebuilds and not even
> realize it at first (or ever).

Yes, if something changes, and people carry on doing the old thing by
habit, then things go wrong.

> Still, the GLEP addresses the very point of what logic has to be
> followed if the EAPI exists in the filename, in the file, or both.  It
> talks of "pre-source" EAPIs and "post-source" EAPIs.  Complicated.

And if the GLEP didn't address it people would complain that it allowed
undefined behaviour.

> Well, in general, if you rely on extensions changing every time a
> program cannot deal with a new feature of a file format, it would be
> quite crazy.  For example, if C programs had to start using ".c-2",
> ".c-3", etc., it would get ugly fast.

Which is why programs that use any major C feature introduced since
1980 use the extension '.cc' or '.cpp'.

> Also, it is easy to build EAPI checking into portage now, and when
> the requisite time passes, you only need to deal with situations
> where *very* old portage versions are still in use.  Since portage is
> typically the first thing the system upgrades after a sync, I don't
> see a big issue.  Or, if that is not acceptable, see my comment at
> the end about a one-time change to a new extension like ".eb".

You completely miss the point of the GLEP. We need new extensions
precisely because current package managers can't handle future EAPIs
cleanly, and we need to carry on using new extensions because otherwise
we restrict what future EAPIs can do.

> But what users *really* don't care about is EAPIs, and this GLEP would
> expose that technical detail to them in a very blatent way.

Anyone who cares about ebuilds at a file level has to care about EAPIs.

> Along those lines, as I've said before, migrating to a new extension,
> *one-time*, as a solution to this, although not optimal, would be far
> more satisfactory than introducing a series of ever-changing
> extensions.

No it won't. It means future EAPIs will be restricted to some
particular source format.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] GLEP 55

[Joe Peterson]

Ciaran McCreesh wrote:
> On Mon, 09 Jun 2008 19:49:08 -0600
> Joe Peterson <lavajoe@gentoo.org> wrote:
>> I'm not saying it's a lot harder.  But it is more complex and less
>> elegant.  Also, it is error-prone.  If someone, by habit, looks for
>> all "*.ebuild", he will miss a portion of the ebuilds and not even
>> realize it at first (or ever).
> 
> Yes, if something changes, and people carry on doing the old thing by
> habit, then things go wrong.

Yes, if everyone is perfect and remembers to do things perfectly right,
there would never be issues in many things, but when you make something
more complicated, there will be more errors.

>> Well, in general, if you rely on extensions changing every time a
>> program cannot deal with a new feature of a file format, it would be
>> quite crazy.  For example, if C programs had to start using ".c-2",
>> ".c-3", etc., it would get ugly fast.
> 
> Which is why programs that use any major C feature introduced since
> 1980 use the extension '.cc' or '.cpp'.

So why would not a one-time new extension (e.g. ".eb") do the trick,
just like ".cc" works for C programs?  Unless you are talking about
needing to specify the EAPI in the file if the more advanced features
are to be used, but I see nothing wrong with that requirement - it's not
much different than specifying a slot, keywords, whatever.

>> Also, it is easy to build EAPI checking into portage now, and when
>> the requisite time passes, you only need to deal with situations
>> where *very* old portage versions are still in use.  Since portage is
>> typically the first thing the system upgrades after a sync, I don't
>> see a big issue.  Or, if that is not acceptable, see my comment at
>> the end about a one-time change to a new extension like ".eb".
> 
> You completely miss the point of the GLEP. We need new extensions
> precisely because current package managers can't handle future EAPIs
> cleanly, and we need to carry on using new extensions because otherwise
> we restrict what future EAPIs can do.

No, I get that.  But once you develop the concept of an EAPI, the very
next package manager version can be aware of it and check the EAPI of an
ebuild.  If the ebuild specifies none, then it is old-style.  If it
specifies one that is unknown or newer than what that package manager
version knows it can handle, it can handle that case (ignore it or
whatever).  I don't see why you need to keep bumping the
filename/extension every time it changes from that point forward.

>> But what users *really* don't care about is EAPIs, and this GLEP would
>> expose that technical detail to them in a very blatent way.
> 
> Anyone who cares about ebuilds at a file level has to care about EAPIs.

Not really.  A typical user does not need to know about EAPIs at all,
but he might want to peruse the portage tree to look for ebuilds.  He
might also want to grep for KEYWORDS or whatever.  The user can delve
into it as much as needed or desired, but if there are these mysterious
EAPI numbers tacked onto the extensions, then it's an added complication
that is not important to all users.

>> Along those lines, as I've said before, migrating to a new extension,
>> *one-time*, as a solution to this, although not optimal, would be far
>> more satisfactory than introducing a series of ever-changing
>> extensions.
> 
> No it won't. It means future EAPIs will be restricted to some
> particular source format.

I assume you mean that EAPI needs to be in the file - again, is this
bad?  Many file formats specify a file format version as part of the file.

						-Joe

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] GLEP 55

[Ciaran McCreesh]

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

On Mon, 09 Jun 2008 20:15:56 -0600
Joe Peterson <lavajoe@gentoo.org> wrote:
> Yes, if everyone is perfect and remembers to do things perfectly
> right, there would never be issues in many things, but when you make
> something more complicated, there will be more errors.

So we shouldn't ever change anything?

> > Which is why programs that use any major C feature introduced since
> > 1980 use the extension '.cc' or '.cpp'.
> 
> So why would not a one-time new extension (e.g. ".eb") do the trick,
> just like ".cc" works for C programs?  Unless you are talking about
> needing to specify the EAPI in the file if the more advanced features
> are to be used, but I see nothing wrong with that requirement - it's
> not much different than specifying a slot, keywords, whatever.

Because then we won't be able to change source compatibility again in
the future without introducing yet another new extension.

> > You completely miss the point of the GLEP. We need new extensions
> > precisely because current package managers can't handle future EAPIs
> > cleanly, and we need to carry on using new extensions because
> > otherwise we restrict what future EAPIs can do.
> 
> No, I get that.  But once you develop the concept of an EAPI, the very
> next package manager version can be aware of it and check the EAPI of
> an ebuild.  If the ebuild specifies none, then it is old-style.  If it
> specifies one that is unknown or newer than what that package manager
> version knows it can handle, it can handle that case (ignore it or
> whatever).  I don't see why you need to keep bumping the
> filename/extension every time it changes from that point forward.

Because the package manager doesn't know how to extract the EAPI from
ebuilds whose EAPI it doesn't support. For example, an EAPI 2 ebuild
might look like this:

    require mypackage using ANIMAL="monkey"

How do current package managers understand that the EAPI there is 2?

> >> But what users *really* don't care about is EAPIs, and this GLEP
> >> would expose that technical detail to them in a very blatent way.
> > 
> > Anyone who cares about ebuilds at a file level has to care about
> > EAPIs.
> 
> Not really.  A typical user does not need to know about EAPIs at all,
> but he might want to peruse the portage tree to look for ebuilds.  He
> might also want to grep for KEYWORDS or whatever.  The user can delve
> into it as much as needed or desired, but if there are these
> mysterious EAPI numbers tacked onto the extensions, then it's an
> added complication that is not important to all users.

The typical user should be using a tool to query that sort of thing.

> >> Along those lines, as I've said before, migrating to a new
> >> extension, *one-time*, as a solution to this, although not
> >> optimal, would be far more satisfactory than introducing a series
> >> of ever-changing extensions.
> > 
> > No it won't. It means future EAPIs will be restricted to some
> > particular source format.
> 
> I assume you mean that EAPI needs to be in the file - again, is this
> bad?  Many file formats specify a file format version as part of the
> file.

It's a pain in the ass, because it means no introducing new global
scope functions and no changing behaviour of existing global scope
functions.

Most file formats don't have to deal with the compatibility issues that
we do. For example, try feeding this C++ program to a C++0x compiler:

void foo(int x)
{
    auto bool requires(x == 1);
}

Or this C++0x program to a C++ compiler:

template <std::Regular T_>
T__ && foo(T_ x)
{
    std::list<std::list<T_>> l;
    return x;
}

In both cases, you get user visible messy errors. That's not something
we have the luxury of being able to do.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] GLEP 55

[Joe Peterson]

Ciaran McCreesh wrote:
> On Mon, 09 Jun 2008 20:15:56 -0600
> Joe Peterson <lavajoe@gentoo.org> wrote:
>> Yes, if everyone is perfect and remembers to do things perfectly
>> right, there would never be issues in many things, but when you make
>> something more complicated, there will be more errors.
> 
> So we shouldn't ever change anything?

Of course I don't mean that.  But humans and computers are each good at
a complementary set of things.  Computers handle obscure complexity
easily; humans do not, so it's better to let computers make our lives
easier rather than the reverse when designing systems.

>> So why would not a one-time new extension (e.g. ".eb") do the trick,
>> just like ".cc" works for C programs?  Unless you are talking about
>> needing to specify the EAPI in the file if the more advanced features
>> are to be used, but I see nothing wrong with that requirement - it's
>> not much different than specifying a slot, keywords, whatever.
> 
> Because then we won't be able to change source compatibility again in
> the future without introducing yet another new extension.

But GLEP 55 is suggesting exactly that: yet another extension for each
new EAPI (I know it is defines this as ".ebuild-<EAPI>", but that is
just semantics).

Source compatibility is not an issue once the EAPI syntax in the file is
defined and the package manager starts to recognize it.  At that point
it can handle the ebuild at whatever EAPI the ebuild declares.  It is
only the older unaware version of the package manager that would get
confused, but that would be solved by a one-time extension change: the
old one would not even look for the new (e.g.) ".eb" extension (only the
old ".ebuild" one), which is exactly what GLEP 55 tries to address.  But
the extension change is only needed once.  Once the EAPI syntax is
introduced and the package manager has code to read it, the package
manager is able to determine the EAPI for all future EAPIs.  If some new
syntax in an as-yet unsupported EAPI exists, the EAPI-version-aware
package manager will not trip on it, since it can just not bother to
deal with "future" EAPI ebuilds.

Now, even if there is no extension change, if we wait long enough, the
chances of an old machine stubbornly staying at an old (pre-EAPI-aware)
portage version gets slimmer and slimmer.  So I'm not even sure this
one-time extension change is really mandatory.  But if it is determined
to be so, I still don't see why we need endless extension changes as
suggested in GLEP 55.

> Because the package manager doesn't know how to extract the EAPI from
> ebuilds whose EAPI it doesn't support. For example, an EAPI 2 ebuild
> might look like this:
> 
>     require mypackage using ANIMAL="monkey"
> 
> How do current package managers understand that the EAPI there is 2?

The old (non-aware) package manager version would not, and yes, it would
fail.  So there are two alternatives: wait long enough or do a one-time
extension change.  In the latter case, the package manager would not
even see the new files.  But the new package manager versions would
determine the EAPI from a defined syntax and ignore ebuilds with
"future" EAPIs.

And I do understand the issue of sourcing, since ebuilds are bash.  If
sourcing is an issue (and I'm not sure it is an overriding one - that's
a good discussion), I would suggest an out-of-band EAPI specifier, but
not in the filename.  Put it in a comment line in the header, like:

# Copyright 1999-2008 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/sys-fs/btrfs-...$
# EAPI=2

inherit eutils
...

So, the first non-blank and non-'#' line (in this case, "inherit ...")
would signify the end of the search for the EAPI= string, making parsing
trivial.  Therefore, the only rule would have to be that "EAPI=" needs
to be in a header comment.  Other rules could be that it needs to be the
only thing on such a header line - whatever.

Again, these are technical details, and I think we can all put our heads
together to come up with the best way to do it.

If sourcing is a better way to go (i.e. to allow EAPI= to be anywhere in
the file with no comment char), caching it might be the answer.  How to
make this efficient would become an implementation detail.

>>>> But what users *really* don't care about is EAPIs, and this GLEP
>>>> would expose that technical detail to them in a very blatent way.
>>> Anyone who cares about ebuilds at a file level has to care about
>>> EAPIs.
>> Not really.  A typical user does not need to know about EAPIs at all,
>> but he might want to peruse the portage tree to look for ebuilds.  He
>> might also want to grep for KEYWORDS or whatever.  The user can delve
>> into it as much as needed or desired, but if there are these
>> mysterious EAPI numbers tacked onto the extensions, then it's an
>> added complication that is not important to all users.
> 
> The typical user should be using a tool to query that sort of thing.

Sure, but my point is: some users *will* want to explore - why not
encourage this?  And if so, why not make the conventions used as clean
and understandable (and elegant) as possible without added noise from
details that do not belong at that (e.g. the filename) level?

Gentoo is a technical distro, and we encourage users to get technical in
every other way.  Saying that they should remain at the portage
interface level is not consistent with that philosophy.

>> I assume you mean that EAPI needs to be in the file - again, is this
>> bad?  Many file formats specify a file format version as part of the
>> file.
> 
> It's a pain in the ass, because it means no introducing new global
> scope functions and no changing behaviour of existing global scope
> functions.
> 
> Most file formats don't have to deal with the compatibility issues that
> we do. For example, try feeding this C++ program to a C++0x compiler...

Right: there are two things to consider: 1) do we want EAPI= to be in
the global bash scope or out of band?, and 2) what happens when the
syntax has errors?

#1 needs more discussion, and #2, yes, should throw an error if invalid,
but this also will be caught when the dev tests his/her ebuild (and/or
by repoman), just as it is today, so I don't see a problem there.  If it
is an EAPI mismatch that would cause the syntax error, the updated
package manager versions would handle it.

						-Joe

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] GLEP 55

[Ciaran McCreesh]

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

On Mon, 09 Jun 2008 21:36:24 -0600
Joe Peterson <lavajoe@gentoo.org> wrote:
> Of course I don't mean that.  But humans and computers are each good
> at a complementary set of things.  Computers handle obscure complexity
> easily; humans do not, so it's better to let computers make our lives
> easier rather than the reverse when designing systems.

And a file extension is far less obscurely complex than enforcing
arbitrary syntax restrictions upon ebuilds.


> >> So why would not a one-time new extension (e.g. ".eb") do the
> >> trick, just like ".cc" works for C programs?  Unless you are
> >> talking about needing to specify the EAPI in the file if the more
> >> advanced features are to be used, but I see nothing wrong with
> >> that requirement - it's not much different than specifying a slot,
> >> keywords, whatever.
> > 
> > Because then we won't be able to change source compatibility again
> > in the future without introducing yet another new extension.
> 
> But GLEP 55 is suggesting exactly that: yet another extension for each
> new EAPI (I know it is defines this as ".ebuild-<EAPI>", but that is
> just semantics).

GLEP 55 suggests a backwards compatible, forwards compatible way of
dealing with the problem that doesn't involve adding new sets of rules
every few EAPIs.

> Source compatibility is not an issue once the EAPI syntax in the file
> is defined and the package manager starts to recognize it.  At that
> point it can handle the ebuild at whatever EAPI the ebuild declares.

No it can't. EAPI has to be known before the source can start. Bash
doesn't provide traps for executing code upon changed variables.

> It is only the older unaware version of the package manager that
> would get confused, but that would be solved by a one-time extension
> change: the old one would not even look for the new (e.g.) ".eb"
> extension (only the old ".ebuild" one), which is exactly what GLEP 55
> tries to address.  But the extension change is only needed once.

No, it's only needed once per non-trivial change. So we might as well
just change it for every EAPI.

> Once the EAPI syntax is introduced and the package manager has code
> to read it, the package manager is able to determine the EAPI for all
> future EAPIs.

Which means we can't change anything useful in future EAPIs. Which,
funnily enough, is what the GLEP is designed to solve.

> Now, even if there is no extension change, if we wait long enough, the
> chances of an old machine stubbornly staying at an old
> (pre-EAPI-aware) portage version gets slimmer and slimmer.  So I'm
> not even sure this one-time extension change is really mandatory.

Except it is, because current EAPI aware package managers still can't
deal with global scope changes.

> > Because the package manager doesn't know how to extract the EAPI
> > from ebuilds whose EAPI it doesn't support. For example, an EAPI 2
> > ebuild might look like this:
> > 
> >     require mypackage using ANIMAL="monkey"
> > 
> > How do current package managers understand that the EAPI there is 2?
> 
> The old (non-aware) package manager version would not, and yes, it
> would fail.  So there are two alternatives: wait long enough or do a
> one-time extension change.  In the latter case, the package manager
> would not even see the new files.  But the new package manager
> versions would determine the EAPI from a defined syntax and ignore
> ebuilds with "future" EAPIs.

And then how do we deal with EAPI 3, where the syntax changes again?

> And I do understand the issue of sourcing, since ebuilds are bash.  If
> sourcing is an issue (and I'm not sure it is an overriding one -
> that's a good discussion), I would suggest an out-of-band EAPI
> specifier, but not in the filename.  Put it in a comment line in the
> header, like:
> 
> # Copyright 1999-2008 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
> # $Header: /var/cvsroot/gentoo-x86/sys-fs/btrfs-...$
> # EAPI=2

Which is way more obscure, complex and arbitrary than a file extension
change. And it still imposes massive restrictions upon future EAPIs.

> Again, these are technical details, and I think we can all put our
> heads together to come up with the best way to do it.

Every issue you've raised so far was already discussed and debunked the
first time this discussion happened. Please read the original
discussions before continuing.

> > The typical user should be using a tool to query that sort of thing.
> 
> Sure, but my point is: some users *will* want to explore - why not
> encourage this?  And if so, why not make the conventions used as clean
> and understandable (and elegant) as possible without added noise from
> details that do not belong at that (e.g. the filename) level?

And when they do explore, they learn straight away what EAPI is.

> Gentoo is a technical distro, and we encourage users to get technical
> in every other way.  Saying that they should remain at the portage
> interface level is not consistent with that philosophy.

And users who get technical knowing what EAPI is is a good thing.

> Right: there are two things to consider: 1) do we want EAPI= to be in
> the global bash scope or out of band?, and 2) what happens when the
> syntax has errors?
> 
> #1 needs more discussion

We had that discussion when the GLEP was first proposed.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] GLEP 55

[Joe Peterson]

Ciaran McCreesh wrote:
> And a file extension is far less obscurely complex than enforcing
> arbitrary syntax restrictions upon ebuilds.

I disagree.  One is exposed to devs only as ebuild syntax; the other is
exposed in an inappropriate location to everyone looking at the portage
tree.

> No it can't. EAPI has to be known before the source can start. Bash
> doesn't provide traps for executing code upon changed variables.

Doing it out-of-band solve this.

> No, it's only needed once per non-trivial change. So we might as well
> just change it for every EAPI.

Huh?  If the "new" portage knows how to determine the EAPI definitively
(and that would be defined), it can deal with the differences.

> And then how do we deal with EAPI 3, where the syntax changes again?

Portage (or whatever PM) reads the EAPI, determines it is 3, and goes
from there.  If you change the way you declare EAPI each time, yeah,
that's a problem, but I'm not sure why that would ne necessary.

> Which is way more obscure, complex and arbitrary than a file extension
> change. And it still imposes massive restrictions upon future EAPIs.

Massive?  Simply a one-line EAPI declaration is not massive nor complex.
 And is more elegant than putting it in the filename.

> Every issue you've raised so far was already discussed and debunked the
> first time this discussion happened. Please read the original
> discussions before continuing.

Debunked according to whom?  I believe that some, including you, believe
you debunked them, but I do not believe there was wholesale agreement
from the dev community.

> We had that discussion when the GLEP was first proposed.

Yes, but nothing was decided, and agreement was not reached.  I'd be
very surprized if I were the only one here who is not entirely satisfied
with GLEP 55's solution to this.

					-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] GLEP 55

[Ciaran McCreesh]

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

On Mon, 09 Jun 2008 22:09:04 -0600
Joe Peterson <lavajoe@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > And a file extension is far less obscurely complex than enforcing
> > arbitrary syntax restrictions upon ebuilds.
> 
> I disagree.  One is exposed to devs only as ebuild syntax; the other
> is exposed in an inappropriate location to everyone looking at the
> portage tree.

You might as well say "We should get rid of Manifest because anyone
looking at the tree is exposed to security internals"...

> > No it can't. EAPI has to be known before the source can start. Bash
> > doesn't provide traps for executing code upon changed variables.
> 
> Doing it out-of-band solve this.

Doing it out-of-band but in-the-file means the file format is fixed in
annoying ways.

> > No, it's only needed once per non-trivial change. So we might as
> > well just change it for every EAPI.
> 
> Huh?  If the "new" portage knows how to determine the EAPI
> definitively (and that would be defined), it can deal with the
> differences.

Sure, until there's another format change. Then we need yet another new
extension. What will we use then? '.ebld'?

The EAPI-in-extension format is cheap. People have been using it for
character sets and languages for decades.

> > And then how do we deal with EAPI 3, where the syntax changes again?
> 
> Portage (or whatever PM) reads the EAPI, determines it is 3, and goes
> from there.  If you change the way you declare EAPI each time, yeah,
> that's a problem, but I'm not sure why that would ne necessary.

But you're not sure that it's not necessary, so why impose entirely
pointless restrictions that everyone in the future has to stick by?

> > Which is way more obscure, complex and arbitrary than a file
> > extension change. And it still imposes massive restrictions upon
> > future EAPIs.
> 
> Massive?  Simply a one-line EAPI declaration is not massive nor
> complex. And is more elegant than putting it in the filename.

You're suddenly imposing restrictions upon the content of comments, and
requiring a whole new parser to deal with it. The point of comments is
that they're ignored.

> > Every issue you've raised so far was already discussed and debunked
> > the first time this discussion happened. Please read the original
> > discussions before continuing.
> 
> Debunked according to whom?  I believe that some, including you,
> believe you debunked them, but I do not believe there was wholesale
> agreement from the dev community.

That doesn't really matter. Most of the dev community don't care to
understand the underlying issue, so all they need to do is go along
with the informed decision that the Council was supposed to have made
on their behalf.

> > We had that discussion when the GLEP was first proposed.
> 
> Yes, but nothing was decided, and agreement was not reached.  I'd be
> very surprized if I were the only one here who is not entirely
> satisfied with GLEP 55's solution to this.

Yet GLEP 55 is the only solution that's been proposed that solves the
requirements. And your entire argument boils down to "file extension
changes don't look pretty", for some arbitrary value of pretty that
also precludes index.html.en and index.html.utf-8.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] GLEP 55

[Donnie Berkholz]

On 05:20 Tue 10 Jun     , Ciaran McCreesh wrote:
> Yet GLEP 55 is the only solution that's been proposed that solves the
> requirements. And your entire argument boils down to "file extension
> changes don't look pretty", for some arbitrary value of pretty that
> also precludes index.html.en and index.html.utf-8.

Did anyone already propose specifying this in metadata.xml? Clearly one 
downside is that PMs would need to be able to parse it to do anything, 
but that would also enable us to do a lot more with metadata.xml that we 
currently don't because we can't have PMs rely on it.

Thanks,
Donnie
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] GLEP 55

[Ciaran McCreesh]

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

On Mon, 9 Jun 2008 22:35:25 -0700
Donnie Berkholz <dberkholz@gentoo.org> wrote:
> Did anyone already propose specifying this in metadata.xml?

Yup. That's a no-go, since metadata.xml is quite rightly treated as
being "not suitable for anything the package manager really needs".

It also moves the EAPI definition even further away from the ebuild,
which makes it even harder to work with.

And, of course, it's not backwards compatible, so it'd still need a
file extension change.

-- 
Ciaran McCreesh

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

[gentoo-dev] Re: GLEP 55

[Tiziano Müller]

Ciaran McCreesh wrote:

> On Mon, 9 Jun 2008 22:35:25 -0700
> Donnie Berkholz <dberkholz@gentoo.org> wrote:
>> Did anyone already propose specifying this in metadata.xml?
> 
> Yup. That's a no-go, since metadata.xml is quite rightly treated as
> being "not suitable for anything the package manager really needs".
> 
> It also moves the EAPI definition even further away from the ebuild,
> which makes it even harder to work with.
> 
> And, of course, it's not backwards compatible, so it'd still need a
> file extension change.
> 

Another ugly solution: Having the EAPI on a per-package (like
$portagedir/cat/package-1) or per-tree basis ($portagedir/profiles/eapi)
and start providing our tree as overlays of more than one tree
(will end up in a mess of dependencies, but it would still be nice to
specify the EAPI for a complete overlay instead of having the name all the
ebuilds like .eapi-X :-).
In addition: it wouldn't be possible to identify the EAPI of an ebuild by
just looking at it...


-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Ciaran McCreesh]

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

On Tue, 10 Jun 2008 10:33:34 +0200
Tiziano Müller <dev-zero@gentoo.org> wrote:
> Another ugly solution: Having the EAPI on a per-package (like
> $portagedir/cat/package-1) or per-tree basis
> ($portagedir/profiles/eapi) and start providing our tree as overlays
> of more than one tree (will end up in a mess of dependencies, but it
> would still be nice to specify the EAPI for a complete overlay
> instead of having the name all the ebuilds like .eapi-X :-).
> In addition: it wouldn't be possible to identify the EAPI of an
> ebuild by just looking at it...

Kills the upgrade path completely. No good.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: GLEP 55

[Luca Barbato]

Ciaran McCreesh wrote:
> Kills the upgrade path completely. No good.

Not really, you change the rsync paths and older portage will pick a 
repo that just has the necessary to upgrade to the next portage.

This kind of things would work better using an scm supporting branches 
and tags a bit better.

lu


-- 

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

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Ciaran McCreesh]

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

On Tue, 10 Jun 2008 11:40:35 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > Kills the upgrade path completely. No good.
> 
> Not really, you change the rsync paths and older portage will pick a 
> repo that just has the necessary to upgrade to the next portage.
> 
> This kind of things would work better using an scm supporting
> branches and tags a bit better.

picard_facepalm.jpg

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: GLEP 55

[Rémi Cardona]

Ciaran McCreesh a écrit :
> picard_facepalm.jpg

I don't think any of us are completely thrilled by either proposals, but 
the EAPI-in-a-separate-file does have the potential for more 
flexibility, ie package-wide EAPI.

And it does keep filenames simple enough.

-- 
Rémi Cardona
LRI, INRIA
remi.cardona@lri.fr
remi@gentoo.org
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Fernando J. Pereda]

On 10 Jun 2008, at 12:30, Rémi Cardona wrote:

> Ciaran McCreesh a écrit :
>> picard_facepalm.jpg
>
> I don't think any of us are completely thrilled by either proposals,  
> but the EAPI-in-a-separate-file does have the potential for more  
> flexibility, ie package-wide EAPI.
>
> And it does keep filenames simple enough.

And it is not backwards compatible.

- ferdy--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Joe Peterson]

Rémi Cardona wrote:
> Ciaran McCreesh a écrit :
>> picard_facepalm.jpg
> 
> I don't think any of us are completely thrilled by either proposals, but 
> the EAPI-in-a-separate-file does have the potential for more 
> flexibility, ie package-wide EAPI.
> 
> And it does keep filenames simple enough.

+1

	-Joe


-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Rémi Cardona]

Ciaran McCreesh a écrit :
> Kills the upgrade path completely. No good.

Lemme sum this up in layman's terms :

1) EAPI _has_ to be known before sourcing an ebuild. There's no way to 
avoid that for various reasons, all 100% valid.

2) Putting the EAPI in the filename :

  + it solves 1)
  + it keeps backward compatibility because old PM won't recognize the 
filenames
  - it's not very "pretty"

3) Putting the EAPI in metadata.xml or in another external file

  + it solves 1)
  + it keeps pretty file names
  - it breaks backwards compatibility
  - (specific to metadata.xml) PM will have to learn to read XML (yuck)

That's about it, right?


-- 
Rémi Cardona
LRI, INRIA
remi.cardona@lri.fr
remi@gentoo.org
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Joe Peterson]

Rémi Cardona wrote:
> Ciaran McCreesh a écrit :
>> Kills the upgrade path completely. No good.
> 
> Lemme sum this up in layman's terms :
> 
> 1) EAPI _has_ to be known before sourcing an ebuild. There's no way to 
> avoid that for various reasons, all 100% valid.
> 
> 2) Putting the EAPI in the filename :
> 
>   + it solves 1)
>   + it keeps backward compatibility because old PM won't recognize the 
> filenames
>   - it's not very "pretty"

I'd say the problems go way beyond just being not pretty.  That longish
email I wrote yesterday has a bunch of reasons I don't like it.  And
"pretty" makes the issue sound unimportant or superficial.

> 3) Putting the EAPI in metadata.xml or in another external file
> 
>   + it solves 1)
>   + it keeps pretty file names
>   - it breaks backwards compatibility
>   - (specific to metadata.xml) PM will have to learn to read XML (yuck)
> 
> That's about it, right?

Good summary, except I think we can find ways to deal with compatibility
(several ideas have been put forth already: giving time for PM to be
upgraded, or a one-time tree or extension bump - and I'm sure there are
even better ones yet to be discussed).  I do not believe that the
filename mangling solution is the "one and only way" as some people are
insisting.

Also, I'm not sure reading XML is a problem at all - python has good
libs for this already.

						-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Fernando J. Pereda]

On 10 Jun 2008, at 15:46, Joe Peterson wrote:
> Also, I'm not sure reading XML is a problem at all - python has good
> libs for this already.

Reading XML files is easy, but it makes certain codepaths much much  
slower. Not a good 'feature'.

- ferdy

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Patrick Börjesson]

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

On 2008-06-10 15:50, Fernando J. Pereda uttered these thoughts:
>
> On 10 Jun 2008, at 15:46, Joe Peterson wrote:
>> Also, I'm not sure reading XML is a problem at all - python has good
>> libs for this already.
>
> Reading XML files is easy, but it makes certain codepaths much much slower. 
> Not a good 'feature'.

... AND there's no requirement for the PM to be written in python or any
other language currently in use. 

-- 
()  The ASCII Ribbon Campaign - against HTML Email
/\  and proprietary formats.

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

Re: [gentoo-dev] Re: GLEP 55

[Richard Freeman]

Rémi Cardona wrote:
> Ciaran McCreesh a écrit :
>> Kills the upgrade path completely. No good.
> 
> Lemme sum this up in layman's terms :
> 
> 1) EAPI _has_ to be known before sourcing an ebuild. There's no way to 
> avoid that for various reasons, all 100% valid.
> 
> 2) Putting the EAPI in the filename :
> 
>  + it solves 1)
>  + it keeps backward compatibility because old PM won't recognize the 
> filenames
>  - it's not very "pretty"
> 
> 3) Putting the EAPI in metadata.xml or in another external file
> 
>  + it solves 1)
>  + it keeps pretty file names
>  - it breaks backwards compatibility
>  - (specific to metadata.xml) PM will have to learn to read XML (yuck)
> 
> That's about it, right?
> 

You missed some options - I'll try to be honest about their pros/cons:

4) Putting EAPI inside the ebuild, but in a manner that does not require 
sourcing using bash (ie comment at top of file).

+ it solves 1)
+ it keeps pretty file names
+ syntax/implementation is trivial
- it breaks backwards compatibility (eventually - hacks might delay this)
- it does force future ebuilds to have the EAPI line in it

5) Putting EAPI inside the ebuild as in #4, but do a one-time-only 
change of the filenames.

+ it solves 1)
+ it sort-of-keeps pretty file names (two pretty extensions instead of one)
+ syntax/implementation is trivial
+ it preserves backwards compatibility
- it does force future ebuilds to have the EAPI line in it

6) Putting EAPI inside the ebuild as in #4, and do a one-time rsync 
location change

+ it solves 1)
+ the filenames don't change at all
+ syntax is trivial, future ebuilds are trivial
+ it preserves backwards compatibility
- it does force future ebuilds to have the EAPI line in it
- it seems like quite a hack - and you end up with a dummy portage tree 
sitting out there for some period of time


Personally, I tend to lean towards either just putting the EAPI in the 
filename, or putting it in the first line and breaking backwards 
compatibility.  The whole reason we're in this mess is the ebuild file 
format does not include a version field or the equivalent of extensible 
headers used in other sorts of files (tar, etc).  We've certainly broken 
backwards-compatibility before with other changes within the distro. 
All we need to do is make it easy to update to a package manager that 
fixes the break and post instructions prominently, and make sure that 
package managers support the new process for a few months before taking 
advantage of it.

Some object to parsing out the EAPI without sourcing the ebuild (only 
bash can source bash).  I disagree with this argument - every time you 
run a shell script it is sourced by something other than bash - the 
kernel has to figure out what script interpreter to use by parsing the 
first line.  There is no reason we can't use a magic number in the same 
way with the EAPI.  That isn't reason enough on its own to put the EAPI 
in the filename, but it is a start.

Most software packages store version information internal to a file 
format.  I'm actually not aware of many that put it in the filename.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Ciaran McCreesh]

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

On Tue, 10 Jun 2008 09:49:04 -0400
Richard Freeman <rich0@gentoo.org> wrote:
> 4) Putting EAPI inside the ebuild, but in a manner that does not
> require sourcing using bash (ie comment at top of file).
> 
> + it solves 1)
> + it keeps pretty file names
> + syntax/implementation is trivial
> - it breaks backwards compatibility (eventually - hacks might delay
> this)
> - it does force future ebuilds to have the EAPI line in it

- it doubles the number of file reads necessary during resolution.
- it heavily restricts future syntax and meaning of EAPIs
- it makes comments have meaning

> Most software packages store version information internal to a file 
> format.  I'm actually not aware of many that put it in the filename.

Most software doesn't have to care about backwards / forwards
compatibility.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: GLEP 55

[Arun Raghavan]

On Tue, Jun 10, 2008 at 7:30 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
[...]
> - it doubles the number of file reads necessary during resolution.

The first read will cause the file to be cached for subsequent reads
anyway, so the performance hit boils down to an additional read() call
(which will probably be buffered by your file I/O library anyway, so
it's unlikely to even result in a context switch). And even without,
it is well worth the lack of fugliness in the ebuild name.

> - it heavily restricts future syntax and meaning of EAPIs

Not by much. It's just a header.

> - it makes comments have meaning

Just as much as #!/bin/bash and # vim: ... do

Regards,
-- 
Arun Raghavan
(http://nemesis.accosted.net)
v2sw5Chw4+5ln4pr6$OFck2ma4+9u8w3+1!m?l7+9GSCKi056
e6+9i4b8/9HTAen4+5g4/8APa2Xs8r1/2p5-8 hackerkey.com
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Ciaran McCreesh]

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

On Tue, 10 Jun 2008 19:38:52 +0530
"Arun Raghavan" <arunisgod@gmail.com> wrote:
> On Tue, Jun 10, 2008 at 7:30 PM, Ciaran McCreesh
> <ciaran.mccreesh@googlemail.com> wrote:
> [...]
> > - it doubles the number of file reads necessary during resolution.
> 
> The first read will cause the file to be cached for subsequent reads
> anyway, so the performance hit boils down to an additional read() call
> (which will probably be buffered by your file I/O library anyway, so
> it's unlikely to even result in a context switch). And even without,
> it is well worth the lack of fugliness in the ebuild name.

No, it results in a new open() on a file that's elsewhere on disk, which
results in two new seeks. You get about fifty seeks per second.

> > - it heavily restricts future syntax and meaning of EAPIs
> 
> Not by much. It's just a header.

<!-- EAPI="3" -->


-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: GLEP 55

[Arun Raghavan]

On Tue, Jun 10, 2008 at 7:44 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
[...]
>> The first read will cause the file to be cached for subsequent reads
>> anyway, so the performance hit boils down to an additional read() call
>> (which will probably be buffered by your file I/O library anyway, so
>> it's unlikely to even result in a context switch). And even without,
>> it is well worth the lack of fugliness in the ebuild name.
>
> No, it results in a new open() on a file that's elsewhere on disk, which
> results in two new seeks. You get about fifty seeks per second.

Well, most file systems have a local structure for this data (=> block
group), so it's not going to be a seek that's very far. Secondly, how
many ebuilds do you need to read directly to get this data in a
typical case? Isn't this what the metadata cache is for?

>> > - it heavily restricts future syntax and meaning of EAPIs
>>
>> Not by much. It's just a header.
>
> <!-- EAPI="3" -->

Do we want to keep the spec so wide open that we support any format
under the Sun that we fancy? Seems like overgeneralizing to me.

Regards,
-- 
Arun Raghavan
(http://nemesis.accosted.net)
v2sw5Chw4+5ln4pr6$OFck2ma4+9u8w3+1!m?l7+9GSCKi056
e6+9i4b8/9HTAen4+5g4/8APa2Xs8r1/2p5-8 hackerkey.com
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Ciaran McCreesh]

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

On Tue, 10 Jun 2008 19:54:33 +0530
"Arun Raghavan" <arunisgod@gmail.com> wrote:
> Well, most file systems have a local structure for this data (=> block
> group), so it's not going to be a seek that's very far. Secondly, how
> many ebuilds do you need to read directly to get this data in a
> typical case? Isn't this what the metadata cache is for?

It's a nice local structure when you're just using a) a nice, linear,
readahead-friendly-ish slurp of the ebuild directory and b) a nice,
linear slurp of files in the metadata cache, which is how things are
now. When you move that to having to make alternating use of the
metadata cache and the ebuild files, you're suddenly seeking backwards
and forwards between two places over and over.

> >> > - it heavily restricts future syntax and meaning of EAPIs
> >>
> >> Not by much. It's just a header.
> >
> > <!-- EAPI="3" -->
> 
> Do we want to keep the spec so wide open that we support any format
> under the Sun that we fancy? Seems like overgeneralizing to me.

We want to keep it open enough that we're not going to have to go
through yet another backwards compatibility breaking change.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: GLEP 55

[Fernando J. Pereda]

On 10 Jun 2008, at 16:14, Ciaran McCreesh wrote:

> On Tue, 10 Jun 2008 19:38:52 +0530
> "Arun Raghavan" <arunisgod@gmail.com> wrote:
>> On Tue, Jun 10, 2008 at 7:30 PM, Ciaran McCreesh
>> <ciaran.mccreesh@googlemail.com> wrote:
>> [...]
>>> - it doubles the number of file reads necessary during resolution.
>>
>> The first read will cause the file to be cached for subsequent reads
>> anyway, so the performance hit boils down to an additional read()  
>> call
>> (which will probably be buffered by your file I/O library anyway, so
>> it's unlikely to even result in a context switch). And even without,
>> it is well worth the lack of fugliness in the ebuild name.
>
> No, it results in a new open() on a file that's elsewhere on disk,  
> which
> results in two new seeks. You get about fifty seeks per second.

Plus path resolution, which isn't exactly free

- ferdy
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Mike Auty]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ciaran McCreesh wrote:
| No, it results in a new open() on a file that's elsewhere on disk, which
| results in two new seeks. You get about fifty seeks per second.

The speed issues aren't really a concern, since the GLEP suggests that
the ebuild must be sourced anyway.  The GLEP allows for a .ebuild-2 file
to contain EAPI="1".  This requires the package manager to source the
ebuild to find out exactly what EAPI should be being used.  The GLEP
doesn't strictly outline what happens to a .ebuild-1 containing EAPI="2"
for a PM that supports EAPI="2" (which needs to be addressed before the
GLEP gets put into action).

It does say a developer should not specify both a pre- and post- source
EAPI, but the GLEP says that if both exist the post-source one is used.
~ That means all package managers would have to source the ebuilds.

Personally, as a developer, I don't want to be messing around with yet
more numbers in the ebuild filenames, and I think it looks ugly.  Not
great arguments, granted.

It also feels like a bad idea to separate information required to
process the contents of the file from the contents of the file itself.
P/PN/PV variables are used in clearly defined locations of the file, and
the script could run under a different name and version (as proved by
every version bump around).  The suggestion seems to be that an ebuild
could not run under a different EAPI.  In that case, the EAPI version
should be embedded in the contents of the file.

As people have pointed out though, there's no need to rush this
decision.  We're simply not going to achieve backwards compatibility
forever (we haven't in the past), so why not choose a time period to
allow for upgrades (6 months, a year?) and implement a new EAPI
definition mechanism that's present in the file and offers a slightly
better compromise between the various parties than the current suggestion?

It will require a little more patience, but it offers time for a thought
out and well designed choice.  What's the rush?

Mike  5:)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkhOpDEACgkQu7rWomwgFXoFvgCeMxSfRiQLEZr3QyT+Bx4b5aNe
/9EAnicrcCQTXxsliAeM4mdisgjO7abg
=tGD8
-----END PGP SIGNATURE-----
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Mike Kelly]

Mike Auty wrote:
> The speed issues aren't really a concern, since the GLEP suggests that
> the ebuild must be sourced anyway.  The GLEP allows for a .ebuild-2 file
> to contain EAPI="1". 

Wrong. From the GLEP: "note that one should *never* explicitly set both 
EAPIs to different values."

Basically, you don't set the post-source EAPI. It is only supposed to be 
used when the pre-source EAPI cannot be determined. This is entirely for 
backwards compatability with EAPI={0,1}. Once people start using 
suffixed EAPIs, EAPI should not (probably "must not") be set in the 
ebuild. Sure, because of how the algorithm works, people could 
potentially do both, but the GLEP makes it pretty clear that they shouldn't.

-- 
Mike Kelly
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Mike Auty]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike Kelly wrote:
| Wrong.

Thanks for that.  I'm gonna assume you meant "I think you're wrong".

| Sure, because of how the algorithm works, people could potentially do
| both, but the GLEP makes it pretty clear that they shouldn't.

It doesn't just say they shouldn't, it *says what happens if they do*:

pkg-4.ebuild-2, EAPI="1"

~    pre-source EAPI is 2, post-source EAPI is 1. EAPI 1 is used

So to live up to the GLEP specification, package managers must source
the ebuild to determine the correct EAPI.

| Basically, you don't set the post-source EAPI. It is only supposed to
| be used when the pre-source EAPI cannot be determined.

If that's what was meant, the GLEP needs changing to say that.
Something like:

pkg-4.ebuild-2, EAPI="X"

~    Pre-source EAPI is 2, post-source EAPI is X.  In this instance the
post-source EAPI is ignored, since a pre-source EAPI is set, so EAPI 2
is used.

It's not a big deal, but it will need a change to the GLEP in its
current form, if that's what's meant.

Mike  5:)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkhPdRUACgkQu7rWomwgFXq1twCgqnFzBqQI8vl63faZ1cq27MF7
7ekAn0aA73nic1v/ovwAUuHsaL44MrTE
=StC2
-----END PGP SIGNATURE-----
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Olivier Galibert]

On Tue, Jun 10, 2008 at 03:14:47PM +0100, Ciaran McCreesh wrote:
> <!-- EAPI="3" -->

*Then* would be the time to change the extension.  As long as the
ebuild is bash-parseable with an appropriate environment, it doesn't
make sense to change the extension because a env-variable set or a
comment are more natural methods.

If/when the format changes to something not parseable by bash, then it
will be time to change the extension.  And then how to mark
(sub-)version will depend on the chosen new format, in case of xml
that would be the dtd information.

I suspect the rejection of the extension change will be there as long
as the fundamental format (bash script) doesn't change.

  OG.

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Santiago M. Mola]

On Wed, Jun 11, 2008 at 12:05 PM, Olivier Galibert <galibert@pobox.com> wrote:
> On Tue, Jun 10, 2008 at 03:14:47PM +0100, Ciaran McCreesh wrote:
>> <!-- EAPI="3" -->
>
> *Then* would be the time to change the extension.  As long as the
> ebuild is bash-parseable with an appropriate environment, it doesn't
> make sense to change the extension because a env-variable set or a
> comment are more natural methods.
>
> If/when the format changes to something not parseable by bash, then it
> will be time to change the extension.  And then how to mark
> (sub-)version will depend on the chosen new format, in case of xml
> that would be the dtd information.
>
> I suspect the rejection of the extension change will be there as long
> as the fundamental format (bash script) doesn't change.
>

If the extension was based on the fact that ebuilds are bash scripts,
they'd have .bash extension. The .ebuild extension means a specific
kind of bash script and it doesn't seem wrong to change the extension
if that "specific kind" changes, even if bash is still the
interpreter. Even if we switched to sh or zsh I doubt we'd use the .sh
or .zsh extension.

Regards,
-- 
Santiago M. Mola
Jabber ID: cooldwind@gmail.com
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Jim Ramsay]

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

Olivier Galibert <galibert@pobox.com> wrote:
> On Tue, Jun 10, 2008 at 03:14:47PM +0100, Ciaran McCreesh wrote:
> > <!-- EAPI="3" -->
> 
> *Then* would be the time to change the extension.  As long as the
> ebuild is bash-parseable with an appropriate environment, it doesn't
> make sense to change the extension because a env-variable set or a
> comment are more natural methods.
> 
> If/when the format changes to something not parseable by bash, then it
> will be time to change the extension.  And then how to mark
> (sub-)version will depend on the chosen new format, in case of xml
> that would be the dtd information.
> 
> I suspect the rejection of the extension change will be there as long
> as the fundamental format (bash script) doesn't change.

Well said.  This is something that I've heard bandied about on IRC now
and then, and sounds to me (notably *not* a package manager developer)
like a fairly reasonable compromise.

To the proponents of GLEP55:

Is there some reason that GLEP55 is preferable to this?

Are there reasons why a particular filename extension could not apply
to a range of EAPIs?

Why not just bump the filename suffix when it is required to support a
new EAPI that breaks the sourcing rules of previous EAPIs?

Or will backwards-incompatible changes be happening so frequently that
the package suffix will have to change for every EAPI bump anyway,
which would make this proposal equivalent to GLEP55?

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)

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

Re: [gentoo-dev] Re: GLEP 55

[Santiago M. Mola]

On Thu, Jun 12, 2008 at 4:07 AM, Jim Ramsay <lack@gentoo.org> wrote:
> Why not just bump the filename suffix when it is required to support a
> new EAPI that breaks the sourcing rules of previous EAPIs?
>
> Or will backwards-incompatible changes be happening so frequently that
> the package suffix will have to change for every EAPI bump anyway,
> which would make this proposal equivalent to GLEP55?

That works. Although, we'd have to keep track of two parameters when
setting our EAPI. One being the EAPI itself and the suffix needed for
that EAPI. So this doesn't seem to make the problem simpler.

Regards,
-- 
Santiago M. Mola
Jabber ID: cooldwind@gmail.com
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Jim Ramsay]

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

"Santiago M. Mola" <coldwind@gentoo.org> wrote:
> On Thu, Jun 12, 2008 at 4:07 AM, Jim Ramsay <lack@gentoo.org> wrote:
> > Why not just bump the filename suffix when it is required to
> > support a new EAPI that breaks the sourcing rules of previous EAPIs?
> >
> > Or will backwards-incompatible changes be happening so frequently
> > that the package suffix will have to change for every EAPI bump
> > anyway, which would make this proposal equivalent to GLEP55?
> 
> That works. Although, we'd have to keep track of two parameters when
> setting our EAPI. One being the EAPI itself and the suffix needed for
> that EAPI. So this doesn't seem to make the problem simpler.

I agree that it doesn't make things simpler.  Though it doesn't make
things that much more complex.  That said, I'm becoming more convinced
that a lot of the changes that really need to be made will indeed break
EAPI sourcing rules, so maybe the latter part of my original quote
above will indeed be the case - This would be equivalent to GLEP55.

I should add that I am not personally opposed to having the EAPI in the
filename, but this may find slightly more acceptance from the folks who
think that solution is incorrect.

-- 
Jim Ramsay
Gentoo Developer (rox/fluxbox/gkrellm)

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

[gentoo-dev] Re: GLEP 55

[Duncan]

Ciaran McCreesh <ciaran.mccreesh@googlemail.com> posted
20080610150018.1cae5e34@googlemail.com, excerpted below, on  Tue, 10 Jun
2008 15:00:18 +0100:

> On Tue, 10 Jun 2008 09:49:04 -0400
> Richard Freeman <rich0@gentoo.org> wrote:
>> 4) Putting EAPI inside the ebuild, but in a manner that does not
>> require sourcing using bash (ie comment at top of file).

> - it doubles the number of file reads necessary during resolution.

No comment, except that it should be cached after the first one, so the 
second read should be a memory read.

> - it heavily restricts future syntax and meaning of EAPIs

I don't see this.  Putting it at a defined place in the ebuild and 
parsing it pre-source nails down the problem such that if a future format 
change is further incompatible, a primary EAPI can be defined that 
defines a further extension, a second line to look at in the ebuild, some 
external file, the filename, whatever, for the additional sub-eapi or 
whatever detail, much as extensions to various Internet RFCs have done 
when they've wanted to extend beyond what would fit in the then-current 
definitions.  It does little to restrict the ultimate combined
primary/secondary EAPI, where the primary simply defines where and how to 
look for the secondary.

> - it makes comments have meaning

Only if we choose the comment format, and then no more than shebang and 
similar solutions do.  In the latter case it's an already recognized *ix 
solution.  In the former, it's entirely possible to use a backward 
compatible EAPI= simple assignment that can be pre-parsed, and use the 
sub-eapi (minor part, in terms discussed elsewhere) if necessary to 
further define it using functions or the like.


That said, I don't see the big deal to putting it in the file extension, 
when we're already breaking traditional content-defines-type rules by 
decreeing .ebuild extensions in the first place.  I'd personally like to 
keep it a one-time fixed extension change, if only to force some 
discipline on the proliferation by forcing each new change to be 
reauthorized, meaning it's /really/ needed or it's simply not worth the 
trouble, but really, the precedent was already set when we accepted 
metadata in filename with the .ebuild thing in the first place, so 
there's little reason to fight it now, unless the proposal also 
eliminates that, and backward compatibility with it.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: GLEP 55

[Duncan]

Duncan <1i5t5.duncan@cox.net> posted pan.2008.06.11.12.52.24@cox.net,
excerpted below, on  Wed, 11 Jun 2008 12:52:24 +0000:

> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> posted
> 20080610150018.1cae5e34@googlemail.com, excerpted below, on  Tue, 10 Jun
> 2008 15:00:18 +0100:
> 
>> On Tue, 10 Jun 2008 09:49:04 -0400
>> Richard Freeman <rich0@gentoo.org> wrote:
>>> 4) Putting EAPI inside the ebuild, but in a manner that does not
>>> require sourcing using bash (ie comment at top of file).
> 
>> - it doubles the number of file reads necessary during resolution.
> 
> No comment, except that it should be cached after the first one, so the
> second read should be a memory read.

Yeah, replying to myself...

Having read the metadata-file/ebuild discussion, I see that despite the 
current sourcing "requirement", it's not being done in practice for 
dependency building during which the EAPI is a necessary data point.  
Only the metadata is being read, thus speeding up the process where seeks 
between metadata and the ebuild would otherwise be needed.  While a 
single additional seek per ebuild would suffice (it'd be in cache after 
that), that could still add up to a LOT of extra seeks (with the 
resultant time and cache usage increase), especially on an --emptytree 
world or similar.

Still, it's essentially required by the current spec even if the now-
current EAPIs manage to avoid it due to similarity of the current EAPIs, 
so it'd be no new imposition.  

The question then becomes, if everything else needed is stored in the pre-
generated metadata cache, why isn't this?  Shouldn't it be there along 
with the rest of the (meta)data used for building the dependency tree, 
thus avoiding the extra seek?  Why not put it in the ebuild as is the 
dependency data, then along with said dependency data, copy it to 
metadata cache when it's generated?

As for backward compatibility on the metadata, append or separate (single 
per repository) file.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Joe Peterson]

Richard Freeman wrote:
> Some object to parsing out the EAPI without sourcing the ebuild (only 
> bash can source bash).  I disagree with this argument - every time you 
> run a shell script it is sourced by something other than bash - the 
> kernel has to figure out what script interpreter to use by parsing the 
> first line.  There is no reason we can't use a magic number in the same 
> way with the EAPI.  That isn't reason enough on its own to put the EAPI 
> in the filename, but it is a start.

+1

It was mentioned that "comments are to be ignored", but you point out a
perfect and very fundamental example of where this is not true:

#!/usr/bin/env bash

Putting another line close to this one with:

#EAPI=42

or

#!EAPI=42

if you like (conforms more to the shell script specifier), is not too
muchh of a stretch.

> Most software packages store version information internal to a file 
> format.  I'm actually not aware of many that put it in the filename.

Only a few, mainly Windows, I believe.  Like .WSn (as pointed out on the
Filename_extension wikipedia page).  But oddballs like this suggest to
me that a hack had to be done because the version could not be gleaned
in a more subtle way from the file itself (e.g. MS Word does this
transparently - all are ".doc").

					-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Federico Ferri]

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

Joe Peterson ha scritto:
> It was mentioned that "comments are to be ignored", but you point out a
> perfect and very fundamental example of where this is not true:
>
> #!/usr/bin/env bash
>
> Putting another line close to this one with:
>
> #EAPI=42
>
> or
>
> #!EAPI=42
>
> if you like (conforms more to the shell script specifier), is not too
> muchh of a stretch.

The so-called shebang; very good in my opinion!

Works very well for true shell scripts. why it can't work for ebuilds?


First, I think of two alternatives:

1) the interpreter is the EAPI (with /usr/bin/ebuild being EAPI=0)
this will be the first line of a EAPI=0 ebuild:

    #!/usr/bin/ebuild

this will be a EAPI=paludis ebuild:

    #!/usr/bin/ebuild-paludis

apparently it's the same mechanism the shell uses to execute a shell 
script, except for the fact that:
 *  ebuild is not an executable file
 *  an external program is used to determine the EAPI (i.e.: extract the 
shebang)


2) fixed interpreter name, use arguments for switching EAPIs

this is another option, wich carries itself a GREAT power of leaving an 
open door when in the future will happen something similar to what we 
have now, where switching the EAPI (or replace EAPI with something else) 
is critical and breaks compatibility.

example - EAPI=0:
    #!/usr/bin/ebuild
    ...
another eapi:
    #!/usr/bin/ebuild -eapi paludis

This allows virtually unlimited cases similar to this; for example when 
switching to <another-feature-that-breaks-things>, another switch will 
be used:

    #!/usr/bin/ebuild -eapi foo -fluffy bar



Advantages of both solutions:
* easy to parse
* doesn't break compatibility

What it does not address:
* doesn't break compatibility

In fact, it should break compatibility.
again I can think of two solutions:
1) change the ebuild extension to a different value, once and 
(hopefully) forever, e.g. from .ebuild to .xbuild, and leave the minimal 
set of .ebuild-s for the upgrade path
2) use two repositories: the legacy one, needed for the upgrade path, 
and the shyny-new-repository with the new ebuilds format


best regards,
Federico Ferri

-- 
#include <stdio.h>
main(){printf("%x",4275974592);}


-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d-(--) a- C++$ UL+++$ L+++$ E--- W++@ w--@
PE PGP+ R- tv-- DI++>+++ D++ h+
------END GEEK CODE BLOCK------



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

Re: [gentoo-dev] Re: GLEP 55

[Santiago M. Mola]

On Tue, Jun 10, 2008 at 10:20 PM, Federico Ferri <xaero@inwind.it> wrote:
>
> The so-called shebang; very good in my opinion!
>
> Works very well for true shell scripts. why it can't work for ebuilds?

This option was already discussed when GLEP 55 was proposed, and in my
opinion it's totally discarded. The concept of shebang doesn't apply
here at all. Plus /usr/bin/ebuild is a binary provided by portage
which has nothing to do with the process of sourcing ebuilds nor even
with the internals of portage (not to speak of other package
managers).

Regards,
-- 
Santiago M. Mola
Jabber ID: cooldwind@gmail.com
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Richard Freeman]

Santiago M. Mola wrote:
> On Tue, Jun 10, 2008 at 10:20 PM, Federico Ferri <xaero@inwind.it> wrote:
>> The so-called shebang; very good in my opinion!
>>
>> Works very well for true shell scripts. why it can't work for ebuilds?
> 
> This option was already discussed when GLEP 55 was proposed, and in my
> opinion it's totally discarded. The concept of shebang doesn't apply
> here at all. Plus /usr/bin/ebuild is a binary provided by portage
> which has nothing to do with the process of sourcing ebuilds nor even
> with the internals of portage (not to speak of other package
> managers).
> 

I had thought of this option as well - I agree that it has a lot of
issues.  I agree that ebuild wouldn't be the right tool, but in the
right framework I could see how something like this might work.

Here is how a portage tree might be handled by a future package manager
that uses shebangs to implement any number of EAPIs that have almost no
restrictions on file contents other than the shebang:

When new "ebuilds" are synced into the repository, they are executed.
If the interpreter doesn't exist, then it is an unsupported EAPI and the
failure is silently ignored (or logged or whatever).  If the interpreter
does exist it will interpret the file properly - perhaps using a EAPI
command-line option from the shebang line or whatever is appropriate for
that EAPI which the interpreter obviously understands.  If the
interpreter determines that the file uses an EAPI it doesn't know, it
aborts execution and skips the package.  That makes the scheme always
backwards compatible (well, at least until the switch to this approach -
current package managers wouldn't be compatible).

When the new ebuild is executed, it will call appropriate functions to
register itself into the local repository.  That registration might
include callbacks of some kind or whatever - the whole way the ebuild
works could vary by EAPI - since the interpreter used by the EAPI could
change.  The only restriction for compatibility is a standard shebang
line.

Each ebuild would only be executed upon a change when it is synced, so
the overhead isn't huge.  At that point all the data is stored in a
local cache and the ebuilds themselves don't get touched until they are
installed.  Installation will work in an EAPI-dependent way - perhaps by
executing the ebuild with a particular parameter or environment setting
or whatever.  The package manager will know since it has already been
established that this is a supported EAPI by the fact that the ebuild
got processed when it was synced in.

This kind of system also makes it easy to support some scenarios that
are currently hard:

1.  Download a random ebuild off the internet and want to add it to your
repository?  Rather than having to put it in a local portage tree you
could just execute it from anywhere and it would register itself in its
present location - and act like any other package in the tree.

2.  No need for utilities like ebuild to manipulate the install process
- instead just execute the ebuild with the appropriate parameters or
whatever to get it to do the install process.

On the other hand, this is a big change from the present, and I'm not 
convinced that it will actually be a big improvement over some of the 
other EAPI ideas being floated around.  However, it is a 
potentially-neat idea...

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Joe Peterson]

Richard Freeman wrote:
> On the other hand, this is a big change from the present, and I'm not 
> convinced that it will actually be a big improvement over some of the 
> other EAPI ideas being floated around.  However, it is a 
> potentially-neat idea...

Rich, interesting thoughts!  But yeah, I agree that for now that is a lot.

My idea for the "#!" thing was much smaller-scale and is a way to add simple
syntax to allow declaration of the EAPI in the file with no sourcing and no
filename extension mangling (plus, no pre-source/post-source issues):

Just have one "shebang-like" line in the header before any real bash code
("#!EAPI=3", "#EAPI=3", or whatever is agreed-upon).  This is out-of-band meta
info, so it's OK that it's in a "comment".  It's ignored by bash, but it can be
read trivially without sourcing.  To accelerate things for the tree (I've seen
others mention this idea too), store the EAPI in the portage cache when it is
generated.

						-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Olivier Galibert]

On Tue, Jun 10, 2008 at 12:01:00PM +0200, Rémi Cardona wrote:
> Ciaran McCreesh a écrit :
> >Kills the upgrade path completely. No good.
> 
> Lemme sum this up in layman's terms :
> 
> 1) EAPI _has_ to be known before sourcing an ebuild. There's no way to 
> avoid that for various reasons, all 100% valid.

"sourcing" != "reading the first line/n first lines/first block and grepping".

  OG.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Rémi Cardona]

Olivier Galibert a écrit :
> On Tue, Jun 10, 2008 at 12:01:00PM +0200, Rémi Cardona wrote:
>> Ciaran McCreesh a écrit :
>>> Kills the upgrade path completely. No good.
>> Lemme sum this up in layman's terms :
>>
>> 1) EAPI _has_ to be known before sourcing an ebuild. There's no way to 
>> avoid that for various reasons, all 100% valid.
> 
> "sourcing" != "reading the first line/n first lines/first block and grepping".

IO-wise, it's the same, as most ebuilds fit inside a kernel memory page 
(ie, 4KB on most arches). So with a cold cache, the time required to 
actually run bash to source the ebuild won't matter much.

But we're getting lost on this thread, let's let it cool off for a 
little while :)

Cheers,

Rémi
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Luca Barbato]

Tiziano Müller wrote:
> Another ugly solution: Having the EAPI on a per-package (like
> $portagedir/cat/package-1) or per-tree basis ($portagedir/profiles/eapi)

I like the per tree basis and I already asked about that (since makes 
things clearer and older portage can be tricked by rsync.

lu

-- 

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

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] GLEP 55

[Joe Peterson]

Ciaran McCreesh wrote:
> On Mon, 9 Jun 2008 22:35:25 -0700
> Donnie Berkholz <dberkholz@gentoo.org> wrote:
>> Did anyone already propose specifying this in metadata.xml?
> 
> Yup. That's a no-go, since metadata.xml is quite rightly treated as
> being "not suitable for anything the package manager really needs".

I think a separate file, especially one that uses a standard XML format,
would be a fine place for things that the PM needs.  Just because we do
not use it this way now does not mean it is not a good idea.  Also, the
EAPI would be out-of-band and not require sourcing of the bash script to
determine.

> It also moves the EAPI definition even further away from the ebuild,
> which makes it even harder to work with.

Harder to work with in what way?

> And, of course, it's not backwards compatible, so it'd still need a
> file extension change.

I am not convinced of this.  As others have stated, portage/PM should be
upgraded with the new capability well in advance of new EAPIs.

					-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] GLEP 55

[Ciaran McCreesh]

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

On Tue, 10 Jun 2008 07:31:09 -0600
Joe Peterson <lavajoe@gentoo.org> wrote:
> I think a separate file, especially one that uses a standard XML
> format, would be a fine place for things that the PM needs.

XML is a pain in the ass.

> Just because we do not use it this way now does not mean it is not a
> good idea.  Also, the EAPI would be out-of-band and not require
> sourcing of the bash script to determine.

The file extension is out-of-band and yet still coupled to the
individual ebuilds in an obvious way.

> > It also moves the EAPI definition even further away from the ebuild,
> > which makes it even harder to work with.
> 
> Harder to work with in what way?

It decouples the EAPI and the thing written in that EAPI.

> > And, of course, it's not backwards compatible, so it'd still need a
> > file extension change.
> 
> I am not convinced of this.  As others have stated, portage/PM should
> be upgraded with the new capability well in advance of new EAPIs.

But that's exactly what EAPIs are there to solve. Having to wait two
years (or however long Gentoo goes between releases these days) just to
use simple new features slows down progress even more.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] GLEP 55

[Richard Freeman]

Ciaran McCreesh wrote:
> On Mon, 09 Jun 2008 22:09:04 -0600
> Joe Peterson <lavajoe@gentoo.org> wrote:
>> Debunked according to whom?  I believe that some, including you,
>> believe you debunked them, but I do not believe there was wholesale
>> agreement from the dev community.
> 
> That doesn't really matter. Most of the dev community don't care to
> understand the underlying issue, so all they need to do is go along
> with the informed decision that the Council was supposed to have made
> on their behalf.
> 

By that logic (that mere ordinary devs need to be guided by their more 
informed elected leaders), we're doing EXACTLY what you propose.  The 
informed decision by the Council was to defer the GLEP.  As a result the 
lesser devs are going along with that decision and not implementing it.

The fact is that most devs probably do care to understand the underlying 
issues.  Many just happen to disagree with you.

I still haven't seen a good argument as to why the EAPI can't be handled 
as something like a magic number.  Maybe make the first line in the ebuild:
#EAPI=foo

ELF vs A.OUT don't use extensions to identify its files - the original 
file format was designed to allow file identification from the contents.

The only issue I can see with putting the EAPI on the first line is with 
legacy package managers.  That could be fixed in a number of ways.  The 
simplest would be just allowing it to break and sending out the fix well 
in advance of any breakage on GMN.  Considering the fiasco that we've 
had with some GCC/GLIBC upgrades and similar stuff in the past this 
would be pretty minor.  A less pretty solution might be a one-time file 
extension change.

There wouldn't be any need to repeat all of this every time the EAPI 
changes - at that point we've standardized the location of the EAPI 
within the file.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] GLEP 55 (why use filename extension?)

[Peter Volkov]

If you need eapi in file name what are the technical reasons of putting
it into file name extension? Why don't you suggest better ebuild name
like:

pkg-ver-eapi.ebuild or pkg-eapi-ver.ebuild ?

I remember last time I've asked this genone told me that this is not
backward compatible. Ok, it's not, but what's the problem to change
extension once only for this change? Call you new files like
pkg-ver-eapi.emerge and that's it! What is the need to change extension
every time you introduce new eapi? Another possibility is to implement
this new file format and wait another one year before using it instead
of crapping the tree for years with such eapi-extesions...

-- 
Peter.

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] GLEP 55 (why use filename extension?)

[Ciaran McCreesh]

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

On Wed, 11 Jun 2008 11:25:50 +0400
Peter Volkov <pva@gentoo.org> wrote:
> If you need eapi in file name what are the technical reasons of
> putting it into file name extension? Why don't you suggest better
> ebuild name like:
> 
> pkg-ver-eapi.ebuild or pkg-eapi-ver.ebuild ?

a) breaks current package managers
b) has no unambiguous parsing
c) looks confusing. pkg-1.2.3-1.ebuild or pkg-1-1.2.3.ebuild look a lot
like Debian-style foo-1.2-3 versions...

> I remember last time I've asked this genone told me that this is not
> backward compatible. Ok, it's not, but what's the problem to change
> extension once only for this change?

It means next time we want to introduce another backward incompatible
change, we have to go through the whole mess all over again.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] GLEP 55 (why use filename extension?)

[Peter Volkov]

В Срд, 11/06/2008 в 08:34 +0100, Ciaran McCreesh пишет:
> On Wed, 11 Jun 2008 11:25:50 +0400
> Peter Volkov <pva@gentoo.org> wrote:
> > If you need eapi in file name what are the technical reasons of
> > putting it into file name extension? Why don't you suggest better
> > ebuild name like:
> > 
> > pkg-ver-eapi.ebuild or pkg-eapi-ver.ebuild ?
> 
> a) breaks current package managers

That's why I suggested to change .ebuild extension or fix package
manager now and wait another year to start using such syntax. Your
answer about extension change

> It means next time we want to introduce another backward incompatible
> change, we have to go through the whole mess all over again.

is not clear. What changes you have in mind? If we already have pkg,
eapi and version in filename what else are you going to add there?

> b) has no unambiguous parsing

Why? For example, just add word eapi and that it: pkg-1.2.3-eapi-1.bld.
That's just an example to show that this is possible.

> c) looks confusing. pkg-1.2.3-1.ebuild or pkg-1-1.2.3.ebuild look a
> lot like Debian-style foo-1.2-3 versions...

Well for me .ebuild-eapi is much more confusing.


I still don't see why it's impossible to have eapi as a part of name but
not in extension...

-- 
Peter.

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] GLEP 55 (why use filename extension?)

[Joe Peterson]

Peter Volkov wrote:
> Well for me .ebuild-eapi is much more confusing.
> 
> I still don't see why it's impossible to have eapi as a part of name but
> not in extension...

Although putting EAPI in the name and not the extension is *slightly*
preferable to using the extension, I still do not think that it even
belongs there for one main design-based reason:

    It does not have to be there from a design perspective.

All other filename components (name-version-revision.ebuild) uniquely
identify the ebuild.  EAPI does not (it is meta-information only needed
internally by the package manager or by someone interpretting the
contents of the file).  You could not have two ebuilds, for example,
that have identical name/version/revision but different EAPIs - that
would not make sense (and yet it would be possible if the EAPI were in
the filename, causing the package manager to need rules for choosing the
right ebuild to look at).

The argument for putting the EAPI in the extension or filename is simply
to address a particular technical implementation detail, and there are
other, better, ways to solve the problem in my opinion.

I would argue that GLEP 54 is also putting needless extra stuff in the
filename, but we won't go there right now.  :)

						-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: GLEP 55

[Tiziano Müller]

Joe Peterson wrote:

> Ciaran McCreesh wrote:
>> And a file extension is far less obscurely complex than enforcing
>> arbitrary syntax restrictions upon ebuilds.
> 
> I disagree.  One is exposed to devs only as ebuild syntax; the other is
> exposed in an inappropriate location to everyone looking at the portage
> tree.
> 
>> No it can't. EAPI has to be known before the source can start. Bash
>> doesn't provide traps for executing code upon changed variables.
> 
> Doing it out-of-band solve this.
> 
>> No, it's only needed once per non-trivial change. So we might as well
>> just change it for every EAPI.
> 
> Huh?  If the "new" portage knows how to determine the EAPI definitively
> (and that would be defined), it can deal with the differences.
> 
>> And then how do we deal with EAPI 3, where the syntax changes again?
> 
> Portage (or whatever PM) reads the EAPI, determines it is 3, and goes
> from there.  If you change the way you declare EAPI each time, yeah,
> that's a problem, but I'm not sure why that would ne necessary.
No, that is not the problem.

Example:
In EAPI 42 we define that the package manager must provide a global function
extract_depend_from_setup_py() such that it is callable at a global level
in an ebuild like this

*snip start*

# Copyright 1999-2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

EAPI=42

DESCRIPTION="A library aiming to support agile and test-driven python
development on various levels."
SRC_URI="http://codespeak.net/download/${PN}/${P}.tar.gz"
HOMEPAGE="http://codespeak.net/py/"
KEYWORDS="~amd64 ~x86"
SLOT="0"
LICENSE="MIT"
IUSE=""

extract_depend_from_setup_py

*snip end*

Now, a package manager (or a tool) not knowing EAPI 42 will fail when it
tries to source the above ebuild to determine the EAPI version (as it is
being currently done as far as I understood it) because
extract_depend_from_setup_py is undefined.
So it won't even be able to read out the EAPI.

With the EAPI in the filename tools now knowing EAPI-42 will either ignore
the above foo-1.0.ebuild-42 or mask it because they may identify the
EAPI-version without sourcing the ebuild.

And: No, just sourcing the ebuild and simply masking it because we can't
source it is a no-go (since you're abusing error-handling as a case
switch).


-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Luca Barbato]

Tiziano Müller wrote:
> Joe Peterson wrote:
> 
>> Ciaran McCreesh wrote:
>>> And a file extension is far less obscurely complex than enforcing
>>> arbitrary syntax restrictions upon ebuilds.
>> I disagree.  One is exposed to devs only as ebuild syntax; the other is
>> exposed in an inappropriate location to everyone looking at the portage
>> tree.
>>
>>> No it can't. EAPI has to be known before the source can start. Bash
>>> doesn't provide traps for executing code upon changed variables.
>> Doing it out-of-band solve this.
>>
>>> No, it's only needed once per non-trivial change. So we might as well
>>> just change it for every EAPI.
>> Huh?  If the "new" portage knows how to determine the EAPI definitively
>> (and that would be defined), it can deal with the differences.
>>
>>> And then how do we deal with EAPI 3, where the syntax changes again?
>> Portage (or whatever PM) reads the EAPI, determines it is 3, and goes
>> from there.  If you change the way you declare EAPI each time, yeah,
>> that's a problem, but I'm not sure why that would ne necessary.
> No, that is not the problem.
> 
> Example:
> In EAPI 42 we define that the package manager must provide a global function
> extract_depend_from_setup_py() such that it is callable at a global level
> in an ebuild like this
> 
> *snip start*
> 
> # Copyright 1999-2007 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
> # $Header: $
> 
> EAPI=42
> 
> DESCRIPTION="A library aiming to support agile and test-driven python
> development on various levels."
> SRC_URI="http://codespeak.net/download/${PN}/${P}.tar.gz"
> HOMEPAGE="http://codespeak.net/py/"
> KEYWORDS="~amd64 ~x86"
> SLOT="0"
> LICENSE="MIT"
> IUSE=""
> 
> extract_depend_from_setup_py
> 
> *snip end*
> 
> Now, a package manager (or a tool) not knowing EAPI 42 will fail when it
> tries to source the above ebuild to determine the EAPI version (as it is
> being currently done as far as I understood it) because
> extract_depend_from_setup_py is undefined.
> So it won't even be able to read out the EAPI.
> 
> With the EAPI in the filename tools now knowing EAPI-42 will either ignore
> the above foo-1.0.ebuild-42 or mask it because they may identify the
> EAPI-version without sourcing the ebuild.
> 

Check if exists a line EAPI=*$, if does and the rest of the string 
matches an understood eapi, go on sourcing, otherwise ignore/mask it...

lu

-- 

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

-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: Re: GLEP 55

[Tiziano Müller]

Luca Barbato wrote:

> Tiziano Müller wrote:
>> Joe Peterson wrote:
>> 
>>> Ciaran McCreesh wrote:
>>>> And a file extension is far less obscurely complex than enforcing
>>>> arbitrary syntax restrictions upon ebuilds.
>>> I disagree.  One is exposed to devs only as ebuild syntax; the other is
>>> exposed in an inappropriate location to everyone looking at the portage
>>> tree.
>>>
>>>> No it can't. EAPI has to be known before the source can start. Bash
>>>> doesn't provide traps for executing code upon changed variables.
>>> Doing it out-of-band solve this.
>>>
>>>> No, it's only needed once per non-trivial change. So we might as well
>>>> just change it for every EAPI.
>>> Huh?  If the "new" portage knows how to determine the EAPI definitively
>>> (and that would be defined), it can deal with the differences.
>>>
>>>> And then how do we deal with EAPI 3, where the syntax changes again?
>>> Portage (or whatever PM) reads the EAPI, determines it is 3, and goes
>>> from there.  If you change the way you declare EAPI each time, yeah,
>>> that's a problem, but I'm not sure why that would ne necessary.
>> No, that is not the problem.
>> 
>> Example:
>> In EAPI 42 we define that the package manager must provide a global
>> function extract_depend_from_setup_py() such that it is callable at a
>> global level in an ebuild like this
>> 
>> *snip start*
>> 
>> # Copyright 1999-2007 Gentoo Foundation
>> # Distributed under the terms of the GNU General Public License v2
>> # $Header: $
>> 
>> EAPI=42
>> 
>> DESCRIPTION="A library aiming to support agile and test-driven python
>> development on various levels."
>> SRC_URI="http://codespeak.net/download/${PN}/${P}.tar.gz"
>> HOMEPAGE="http://codespeak.net/py/"
>> KEYWORDS="~amd64 ~x86"
>> SLOT="0"
>> LICENSE="MIT"
>> IUSE=""
>> 
>> extract_depend_from_setup_py
>> 
>> *snip end*
>> 
>> Now, a package manager (or a tool) not knowing EAPI 42 will fail when it
>> tries to source the above ebuild to determine the EAPI version (as it is
>> being currently done as far as I understood it) because
>> extract_depend_from_setup_py is undefined.
>> So it won't even be able to read out the EAPI.
>> 
>> With the EAPI in the filename tools now knowing EAPI-42 will either
>> ignore the above foo-1.0.ebuild-42 or mask it because they may identify
>> the EAPI-version without sourcing the ebuild.
>> 
> 
> Check if exists a line EAPI=*$, if does and the rest of the string
> matches an understood eapi, go on sourcing, otherwise ignore/mask it...

... and package managers which don't do that already still fail.


-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Re: GLEP 55

[Luca Barbato]

Tiziano Müller wrote:
> ... and package managers which don't do that already still fail.

To put everything in perspective all this discussion is done in order to 
workaround the issue of an old and outdated package manager that cannot 
be upgraded once it syncs from a too new repository.

The simplest way is to change the syncpoint in the new package manager 
and leave the previous uri with a compatibility repo for the older ones.

lu

-- 

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

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Re: GLEP 55

[Ciaran McCreesh]

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

On Tue, 10 Jun 2008 12:22:03 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> Tiziano Müller wrote:
> > ... and package managers which don't do that already still fail.
> 
> To put everything in perspective all this discussion is done in order
> to workaround the issue of an old and outdated package manager that
> cannot be upgraded once it syncs from a too new repository.
> 
> The simplest way is to change the syncpoint in the new package
> manager and leave the previous uri with a compatibility repo for the
> older ones.

So you're volunteering to convert the entire tree to the new EAPI all
in one go every two months?

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: Re: GLEP 55

[Luca Barbato]

Ciaran McCreesh wrote:
> So you're volunteering to convert the entire tree to the new EAPI all
> in one go every two months?

I don't see the need and I won't see the problem given right now what is 
interesting is the set of improvements that aren't forward incompatible.

Being that the case you'd just need 2 trees, managed as overlay and a 
marker for each tree on which eapi to use, but I dislike empty theories 
or hardly searched corner cases that could be avoided with half of the 
effort necessary to get there.


lu

-- 

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

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Re: GLEP 55

[Ciaran McCreesh]

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

On Tue, 10 Jun 2008 13:13:34 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > So you're volunteering to convert the entire tree to the new EAPI
> > all in one go every two months?
> 
> I don't see the need and I won't see the problem given right now what
> is interesting is the set of improvements that aren't forward
> incompatible.

It's likely that any future EAPIs won't be forward compatible because:

* There's a strong desire to make lots of functions stricter.
* The current *DEPEND syntax will probably be replaced with something
more expressive.
* There'll be more phases.

So yes, it's a full tree rewrite if you want to avoid having multiple
EAPIs in the same tree.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: Re: GLEP 55

[Fernando J. Pereda]

On 10 Jun 2008, at 13:13, Luca Barbato wrote:
> but I dislike empty theories or hardly searched corner cases that  
> could be avoided with half of the effort necessary to get there.

Yoy mean like adopting GLEP55, right?

- ferdy

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Re: GLEP 55

[Piotr Jaroszyński]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 289 bytes --]

> The simplest way is to change the syncpoint in the new package manager and
> leave the previous uri with a compatibility repo for the older ones.

So we add a new repo each time a new EAPI comes out? Sounds like a big mess.

-- 
Best Regards,
Piotr Jaroszyński
éí¢‡^¾X¬¶È\x1ežÚ(¢¸&j)bž	b²

Re: [gentoo-dev] Re: Re: GLEP 55

[Luca Barbato]

Piotr Jaroszyński wrote:
>> The simplest way is to change the syncpoint in the new package manager and
>> leave the previous uri with a compatibility repo for the older ones.
> 
> So we add a new repo each time a new EAPI comes out? Sounds like a big mess.

It isn't you just keep 2 repos, one with the minimal eapi and the 
minimal set of ebuilds needed to upgrade, one with the latest and greatest.

lu

-- 

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

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Re: GLEP 55

[Bernd Steinhauser]

Luca Barbato schrieb:
> Piotr Jaroszyński wrote:
>>> The simplest way is to change the syncpoint in the new package 
>>> manager and
>>> leave the previous uri with a compatibility repo for the older ones.
>>
>> So we add a new repo each time a new EAPI comes out? Sounds like a big 
>> mess.
> 
> It isn't you just keep 2 repos, one with the minimal eapi and the 
> minimal set of ebuilds needed to upgrade, one with the latest and greatest.
> 
> lu
> 
Then you could also just provide binaries...

But lets face it, it slows down progress, because you will delay every 
change, because stuff like that you will only do if necessary.
And it is still huge pain, from a users point of view, to upgrade stuff.

And that is, what this is about, making EAPI bumps as less painful as 
possible. The filename is the easiest solution for that.

I really fail to see the point, why it is so important, that the 
extension will still be .ebuild in the future.

There is a lot of software, that keeps using the same filename for 
different versions of stuff and in many cases, that is a huge mess.

I still haven't seen any good reasons against it.
And btw, the KDE overlay users don't seem at all to be confused, because 
the packages are named .kdebuild-1 instead of .ebuild.
Portage (and other tools) keeps happily ignoring them, like it should.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Re: GLEP 55

[Joe Peterson]

Bernd Steinhauser wrote:
> And that is, what this is about, making EAPI bumps as less painful as 
> possible. The filename is the easiest solution for that.

In any design, there are "easy" short-cuts that can be taken.  But
sometimes these short-cuts break paradigms that are fundamental.  If you
wanted, you could throw a bunch of things into the filename and make it
255 characters long to avoid reading the file, but that clearly would be
a pretty bad design.

> I really fail to see the point, why it is so important, that the 
> extension will still be .ebuild in the future.
> 
> There is a lot of software, that keeps using the same filename for 
> different versions of stuff and in many cases, that is a huge mess.

Is the "huge mess" you are thinking of the basic reality that software
of any reasonable complexity needs to deal with file formats evolving?
If so, that is exactly why EAPIs now are being introduced.

But almost all software deals with this transparently - no need to
expose it to the user, and sticking the version in the filename is both
fragile (renaming the file can alter it) and seems like a hack.

> I still haven't seen any good reasons against it.

I realize that there are two camps of people here.  One camp sees
mangling the filename extension as an undesirable way to deal with this,
and the other camp simply sees no problem with this.

I want to point out, however, that the fact that you do not see the
issue does not make the issue invalid.  I am sure there are people who
work at Apple who care nothing about the way an iPhone looks or feels
and only care that it works correctly.  If that person went to Steve
Jobs and said, "Why are you spending so much money to make this thing
look cool?", he would say that Apple is known for making cool things,
and no one would buy something that works great but looks like a piece
of junk.  He'd be right.

I realize this analogy is a bit of an exaggeration, but there is no
reason we cannot make EAPIs work correctly and very efficiently (this is
where technical innovation comes in), while also keeping the basic
interface (and I include file name convention here) clean, standard,
uncluttered, uncomplicated, and elegant.

						-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Re: GLEP 55

[Ciaran McCreesh]

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

On Tue, 10 Jun 2008 09:02:29 -0600
Joe Peterson <lavajoe@gentoo.org> wrote:
> But almost all software deals with this transparently - no need to
> expose it to the user, and sticking the version in the filename is
> both fragile (renaming the file can alter it) and seems like a hack.

The typical user does not deal with the ebuild files themselves, and
if they are doing so it's because there's a deficiency in the tools
available to them. Any user who *does* deal with ebuild files is doing
something sufficiently advanced that they need to be aware of EAPIs
anyway.

As for fragile... You might as well say that sticking PN and PV in the
file is fragile and a hack...

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: Re: GLEP 55

[Bernd Steinhauser]

Joe Peterson schrieb:
> Bernd Steinhauser wrote:
>> And that is, what this is about, making EAPI bumps as less painful as 
>> possible. The filename is the easiest solution for that.
> 
> In any design, there are "easy" short-cuts that can be taken.  But
> sometimes these short-cuts break paradigms that are fundamental.  If you
> wanted, you could throw a bunch of things into the filename and make it
> 255 characters long to avoid reading the file, but that clearly would be
> a pretty bad design.
Yes, in principle you could do that, but in principle you could do the 
same with the first line in a file or whatever you are suggesting.


>> I really fail to see the point, why it is so important, that the 
>> extension will still be .ebuild in the future.
>>
>> There is a lot of software, that keeps using the same filename for 
>> different versions of stuff and in many cases, that is a huge mess.
> 
> Is the "huge mess" you are thinking of the basic reality that software
> of any reasonable complexity needs to deal with file formats evolving?
> If so, that is exactly why EAPIs now are being introduced.
> 
> But almost all software deals with this transparently - no need to
> expose it to the user, and sticking the version in the filename is both
> fragile (renaming the file can alter it) and seems like a hack.
Wow, altering the content of a file can alter it, too. What is the point 
there?
BTW, so you are suggesting, that we shouldn't put the PV in the file name?
We shouldn't put the revision in the file name?

Hm, so in the future, there will be a "metadata.xml" file, that defines:
- EAPI
- PV
- KEYWORDS
- more stuff
of  the ebuild? Sounds complicated.

>> I still haven't seen any good reasons against it.
> 
> I realize that there are two camps of people here.  One camp sees
> mangling the filename extension as an undesirable way to deal with this,
> and the other camp simply sees no problem with this.
Seems to be like that.
But I am really impress, how far some people go, to avoid renaming the 
file extension of a file.


-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Joe Peterson]

Luca Barbato wrote:
> Check if exists a line EAPI=*$, if does and the rest of the string 
> matches an understood eapi, go on sourcing, otherwise ignore/mask it...

And placing it out-of-band (like "# EAPI=...") avoids any sourcing
errors, makes parsing faster, etc.

			-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Fernando J. Pereda]

On 10 Jun 2008, at 15:33, Joe Peterson wrote:

> Luca Barbato wrote:
>> Check if exists a line EAPI=*$, if does and the rest of the string
>> matches an understood eapi, go on sourcing, otherwise ignore/mask  
>> it...
>
> And placing it out-of-band (like "# EAPI=...") avoids any sourcing
> errors, makes parsing faster, etc.

No, it doesn't make parsing faster. Had you bothered to profile any  
package manager you'd know that.

- ferdy


-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Luca Barbato]

Fernando J. Pereda wrote:
> 
> No, it doesn't make parsing faster. Had you bothered to profile any 
> package manager you'd know that.

Do you have any number to share?

lu

-- 

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

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Fernando J. Pereda]

On 10 Jun 2008, at 15:48, Luca Barbato wrote:

> Fernando J. Pereda wrote:
>> No, it doesn't make parsing faster. Had you bothered to profile any  
>> package manager you'd know that.
>
> Do you have any number to share?

What number are you interested in?

- ferdy

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Luca Barbato]

Fernando J. Pereda wrote:
> 
> On 10 Jun 2008, at 15:48, Luca Barbato wrote:
> 
>> Fernando J. Pereda wrote:
>>> No, it doesn't make parsing faster. *Had you bothered to profile any 
>>> package manager you'd know that.*
>>
>> Do you have any number to share?
> 
> What number are you interested in?

Profiling numbers...

lu

-- 

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

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Joe Peterson]

Fernando J. Pereda wrote:
> On 10 Jun 2008, at 15:33, Joe Peterson wrote:
> 
>> Luca Barbato wrote:
>>> Check if exists a line EAPI=*$, if does and the rest of the string
>>> matches an understood eapi, go on sourcing, otherwise ignore/mask  
>>> it...
>> And placing it out-of-band (like "# EAPI=...") avoids any sourcing
>> errors, makes parsing faster, etc.
> 
> No, it doesn't make parsing faster. Had you bothered to profile any  
> package manager you'd know that.

No, I have not profiled PMs to try this, but you are saying that reading
the first few lines of a file is not faster than sourcing the whole
thing with bash?  Remember that it could abort the minute it sees a non
'#' or blank line, which would be after the first few.

					-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Richard Freeman]

Joe Peterson wrote:
> 
> No, I have not profiled PMs to try this, but you are saying that reading
> the first few lines of a file is not faster than sourcing the whole
> thing with bash?  Remember that it could abort the minute it sees a non
> '#' or blank line, which would be after the first few.
> 

Actually, if you specified that the EAPI goes on the first line, then 
you'd only need to read the first line.

And to the extent that the rest got read into memory anyway by the 
kernel, well then it is already in the cache when whatever mechanism is 
invoked to parse the rest of the file.

I don't think that filename-vs-first-line is going to make a big 
difference in practical performance.  Any time lost in determining EAPI 
would be time saved in parsing the file.  And even though you could 
ignore unknown EAPIs, I think that in a typical case users would be 
using an up-to-date package manager that would just end up parsing 
everything all the time anyway.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Ciaran McCreesh]

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

On Tue, 10 Jun 2008 09:56:18 -0400
Richard Freeman <rich0@gentoo.org> wrote:
> Joe Peterson wrote:
> > No, I have not profiled PMs to try this, but you are saying that
> > reading the first few lines of a file is not faster than sourcing
> > the whole thing with bash?  Remember that it could abort the minute
> > it sees a non '#' or blank line, which would be after the first few.
> > 
> 
> Actually, if you specified that the EAPI goes on the first line, then 
> you'd only need to read the first line.
> 
> And to the extent that the rest got read into memory anyway by the 
> kernel, well then it is already in the cache when whatever mechanism
> is invoked to parse the rest of the file.

Except that currently, the ebuild file isn't opened for read. So it's
not in memory at all.

> I don't think that filename-vs-first-line is going to make a big 
> difference in practical performance.

It's about a factor of five difference in cold-cache resolution
performance for Paludis.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: GLEP 55

[Arun Raghavan]

On Tue, Jun 10, 2008 at 7:32 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
[...]
>> I don't think that filename-vs-first-line is going to make a big
>> difference in practical performance.
>
> It's about a factor of five difference in cold-cache resolution
> performance for Paludis.

Could you please share more details on the experiment that showed this
kind of performance degradation and the numbers, if possible?

Thanks,
-- 
Arun Raghavan
(http://nemesis.accosted.net)
v2sw5Chw4+5ln4pr6$OFck2ma4+9u8w3+1!m?l7+9GSCKi056
e6+9i4b8/9HTAen4+5g4/8APa2Xs8r1/2p5-8 hackerkey.com
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Ciaran McCreesh]

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

On Tue, 10 Jun 2008 19:40:22 +0530
"Arun Raghavan" <arunisgod@gmail.com> wrote:
> On Tue, Jun 10, 2008 at 7:32 PM, Ciaran McCreesh
> <ciaran.mccreesh@googlemail.com> wrote:
> [...]
> >> I don't think that filename-vs-first-line is going to make a big
> >> difference in practical performance.
> >
> > It's about a factor of five difference in cold-cache resolution
> > performance for Paludis.
> 
> Could you please share more details on the experiment that showed this
> kind of performance degradation and the numbers, if possible?

Shove an open and a getline in when doing what would otherwise be a
successful cache read. It adds a couple of thousand new open()s on
files that would otherwise be left alone, and changes the nice linear
"slurp up things in this directory in order until we don't need
anything else" pattern into "bounce backwards and forwards between lots
of files in two different directories".

On a cold cache, which is the most common use case, this is very very
nasty.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: GLEP 55

[Richard Freeman]

Ciaran McCreesh wrote:
> On Tue, 10 Jun 2008 19:40:22 +0530
> "Arun Raghavan" <arunisgod@gmail.com> wrote:
>> On Tue, Jun 10, 2008 at 7:32 PM, Ciaran McCreesh
>> <ciaran.mccreesh@googlemail.com> wrote:
>> [...]
>>>> I don't think that filename-vs-first-line is going to make a big
>>>> difference in practical performance.
>>> It's about a factor of five difference in cold-cache resolution
>>> performance for Paludis.
>> Could you please share more details on the experiment that showed this
>> kind of performance degradation and the numbers, if possible?
> 
> Shove an open and a getline in when doing what would otherwise be a
> successful cache read. It adds a couple of thousand new open()s on
> files that would otherwise be left alone, and changes the nice linear
> "slurp up things in this directory in order until we don't need
> anything else" pattern into "bounce backwards and forwards between lots
> of files in two different directories".
> 
> On a cold cache, which is the most common use case, this is very very
> nasty.
> 

I'm curious as to what operation in particular we're looking at.  Let's 
say I type in "paludis --sync":

Obviously the first step is to rsync the portage tree.  Then we find all 
modified files (already output by rsync) and update the caches.  We 
already need to fully parse every file to create a dependency tree, so 
why is it slow to cache the EAPI for each file while we're at it?

Next, suppose I type in "paludis -pi world":

Why wouldn't everything you need not already be in the cache?  And if 
something wasn't, then why is reading in the EAPI any slower than 
reading in (R)DEPEND/KEYWORDS/IUSE/etc?

What specific operation (from an end-user perspective) is improved by 
putting EAPI in the filename?  I'm not interested in theoretical 
operations like "given a portage tree, find the EAPI of every file" - 
users don't do those operations routinely in isolation, but as part of 
larger operations where doing an open and a getline now just speeds up 
the open and getline that would be executed 500 lines later anyway.

Again, I'm not completely opposed to the idea of putting EAPI in the 
filename, but I'm not convinced that the arguments in favor of it are as 
clear-cut as some are suggesting.  If everybody was open about the 
pros/cons of each solution and not suggesting that one solution is 
near-perfect and the others are total non-starters then this whole 
debate would probably be a whole lot less contentious.  When people 
perceive that somebody isn't honest about the shortcomings of their own 
proposal then they're less likely to trust them - it is just a human 
thing...
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Ciaran McCreesh]

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

On Tue, 10 Jun 2008 11:08:21 -0400
Richard Freeman <rich0@gentoo.org> wrote:
> I'm curious as to what operation in particular we're looking at.
> Let's say I type in "paludis --sync":

paludis --sync doesn't use metadata.

> Next, suppose I type in "paludis -pi world":

If it's straight after a --sync, then yes, some things are pre-loaded
by rsync. Similarly, if it's straight after other operations, then yes,
some things are pre-loaded. But we don't plan for "just the use cases
that make our life easy".

> Why wouldn't everything you need not already be in the cache?  And if 
> something wasn't, then why is reading in the EAPI any slower than 
> reading in (R)DEPEND/KEYWORDS/IUSE/etc?

Currently we don't touch the ebuild's content *at all* for metadata
operations, except where there's no or stale metadata cache (which is
rare). We can get away with this currently because 0 and 1 have
identical cache layouts and PMS has some (necessary) weasel wording;
future EAPIs likely won't, so we're back to the chicken / egg problem.

So... We either have the EAPI from the extension (which we already
have, since we have to read the dir to know what versions are
available), in which case we know how to read the metadata cache file.
Or we have to open up a file that would otherwise not be opened, just
to parse one line so we know how to read the cache file.

> What specific operation (from an end-user perspective) is improved by 
> putting EAPI in the filename?  I'm not interested in theoretical 
> operations like "given a portage tree, find the EAPI of every file" - 
> users don't do those operations routinely in isolation, but as part
> of larger operations where doing an open and a getline now just
> speeds up the open and getline that would be executed 500 lines later
> anyway.

paludis -pi anything on a cold cache.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: GLEP 55

[Thomas de Grenier de Latour]

On 2008/06/10, Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> Currently we don't touch the ebuild's content *at all* for metadata
> operations, except where there's no or stale metadata cache (which is
> rare). We can get away with this currently because 0 and 1 have
> identical cache layouts and PMS has some (necessary) weasel wording;
> future EAPIs likely won't, so we're back to the chicken / egg problem.
> 
> So... We either have the EAPI from the extension (which we already
> have, since we have to read the dir to know what versions are
> available), in which case we know how to read the metadata cache file.
> Or we have to open up a file that would otherwise not be opened, just
> to parse one line so we know how to read the cache file.

Or you apply to future EAPI's cache formats one of the solutions that
have been proposed for the ebuild side of the very same "chicken / egg
problem": for instance, you could use $EAPI as cache filename extension. 

And that's it, you can get EAPI from the cache, hence no more extra
reading of ebuild files, and no more perfs issues.

It sounds so simple, am I missing something obvious?

-- 
TGL.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Ciaran McCreesh]

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

On Wed, 11 Jun 2008 01:36:01 +0200
Thomas de Grenier de Latour <tom.gl@free.fr> wrote:
> Or you apply to future EAPI's cache formats one of the solutions that
> have been proposed for the ebuild side of the very same "chicken / egg
> problem": for instance, you could use $EAPI as cache filename
> extension. 
> 
> And that's it, you can get EAPI from the cache, hence no more extra
> reading of ebuild files, and no more perfs issues.
> 
> It sounds so simple, am I missing something obvious?

You're missing the cases where the cache isn't usable.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: GLEP 55

[Thomas de Grenier de Latour]

On 2008/06/11, Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> You're missing the cases where the cache isn't usable.
> 

I was not talking about generating cache entries, and neither were you.
I've replied to you because you were suggesting that the "EAPI in
ebuilds contents" solution had extra cost when _using_ valid cache
entries (need to extract the EAPI from the ebuild before reading this
cache entry), which i think can be easily avoided.

On 2008/06/10, Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> Currently we don't touch the ebuild's content *at all* for metadata
> operations, except where there's no or stale metadata cache (which is
> rare). We can get away with this currently because 0 and 1 have
> identical cache layouts and PMS has some (necessary) weasel wording;
> future EAPIs likely won't, so we're back to the chicken / egg problem.
> 
> So... We either have the EAPI from the extension (which we already
> have, since we have to read the dir to know what versions are
> available), in which case we know how to read the metadata cache file.
> Or we have to open up a file that would otherwise not be opened, just
> to parse one line so we know how to read the cache file.

-- 
TGL.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Ciaran McCreesh]

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

On Wed, 11 Jun 2008 08:31:45 +0200
Thomas de Grenier de Latour <tom.gl@free.fr> wrote:
> On 2008/06/11, Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > You're missing the cases where the cache isn't usable.
> 
> I was not talking about generating cache entries, and neither were
> you. I've replied to you because you were suggesting that the "EAPI in
> ebuilds contents" solution had extra cost when _using_ valid cache
> entries (need to extract the EAPI from the ebuild before reading this
> cache entry), which i think can be easily avoided.

And it does, since EAPI has to be known to use the cache contents. The
way it's handled currently is a hack that doesn't work with future EAPIs
defining new metadata.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: GLEP 55

[Arun Raghavan]

On Wed, Jun 11, 2008 at 12:06 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Wed, 11 Jun 2008 08:31:45 +0200
> Thomas de Grenier de Latour <tom.gl@free.fr> wrote:
>> On 2008/06/11, Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
>> > You're missing the cases where the cache isn't usable.
>>
>> I was not talking about generating cache entries, and neither were
>> you. I've replied to you because you were suggesting that the "EAPI in
>> ebuilds contents" solution had extra cost when _using_ valid cache
>> entries (need to extract the EAPI from the ebuild before reading this
>> cache entry), which i think can be easily avoided.
>
> And it does, since EAPI has to be known to use the cache contents. The
> way it's handled currently is a hack that doesn't work with future EAPIs
> defining new metadata.

Fix that, then. And I understand that the code is already there in
both portage and pkgcore to store the cache as key-value pairs rather
than one-slot-per-key, and would be relatively trivial to add to
paludis.

Regards,
-- 
Arun Raghavan
(http://nemesis.accosted.net)
v2sw5Chw4+5ln4pr6$OFck2ma4+9u8w3+1!m?l7+9GSCKi056
e6+9i4b8/9HTAen4+5g4/8APa2Xs8r1/2p5-8 hackerkey.com
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Olivier Galibert]

On Tue, Jun 10, 2008 at 03:02:28PM +0100, Ciaran McCreesh wrote:
> Except that currently, the ebuild file isn't opened for read. So it's
> not in memory at all.

Why would you need the EAPI before the time when you actually want to
interpret the contents?	

  OG.

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Ciaran McCreesh]

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

On Tue, 10 Jun 2008 19:14:11 +0200
Olivier Galibert <galibert@pobox.com> wrote:
> On Tue, Jun 10, 2008 at 03:02:28PM +0100, Ciaran McCreesh wrote:
> > Except that currently, the ebuild file isn't opened for read. So
> > it's not in memory at all.
> 
> Why would you need the EAPI before the time when you actually want to
> interpret the contents?	

You need the EAPI before you use the metadata. But you don't need the
ebuild to get the metadata in the common case.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: GLEP 55

[Arun Raghavan]

On Wed, Jun 11, 2008 at 8:44 AM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
[...]
>> Why would you need the EAPI before the time when you actually want to
>> interpret the contents?
>
> You need the EAPI before you use the metadata. But you don't need the
> ebuild to get the metadata in the common case.

Does the cache format _really_ need to be extensible the extent that
we're jumping hoops to support arbitrary cache formats?
-- 
Arun Raghavan
(http://nemesis.accosted.net)
v2sw5Chw4+5ln4pr6$OFck2ma4+9u8w3+1!m?l7+9GSCKi056
e6+9i4b8/9HTAen4+5g4/8APa2Xs8r1/2p5-8 hackerkey.com
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Ciaran McCreesh]

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

On Wed, 11 Jun 2008 09:52:17 +0530
"Arun Raghavan" <arunisgod@gmail.com> wrote:
> On Wed, Jun 11, 2008 at 8:44 AM, Ciaran McCreesh
> <ciaran.mccreesh@googlemail.com> wrote:
> [...]
> >> Why would you need the EAPI before the time when you actually want
> >> to interpret the contents?
> >
> > You need the EAPI before you use the metadata. But you don't need
> > the ebuild to get the metadata in the common case.
> 
> Does the cache format _really_ need to be extensible the extent that
> we're jumping hoops to support arbitrary cache formats?

The cache format needs to be able to have keys added and removed from
it.

But the cache format is largely irrelevant here. There aren't any
non-trivial EAPI related problems introduced by cache that don't already
exist without cache.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: GLEP 55

[Olivier Galibert]

On Wed, Jun 11, 2008 at 04:14:58AM +0100, Ciaran McCreesh wrote:
> On Tue, 10 Jun 2008 19:14:11 +0200
> Olivier Galibert <galibert@pobox.com> wrote:
> > On Tue, Jun 10, 2008 at 03:02:28PM +0100, Ciaran McCreesh wrote:
> > > Except that currently, the ebuild file isn't opened for read. So
> > > it's not in memory at all.
> > 
> > Why would you need the EAPI before the time when you actually want to
> > interpret the contents?	
> 
> You need the EAPI before you use the metadata. But you don't need the
> ebuild to get the metadata in the common case.

The metadata should carry its version indicator too.

  OG.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Ciaran McCreesh]

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

On Tue, 10 Jun 2008 07:49:31 -0600
Joe Peterson <lavajoe@gentoo.org> wrote:
> > No, it doesn't make parsing faster. Had you bothered to profile
> > any package manager you'd know that.
> 
> No, I have not profiled PMs to try this, but you are saying that
> reading the first few lines of a file is not faster than sourcing the
> whole thing with bash?  Remember that it could abort the minute it
> sees a non '#' or blank line, which would be after the first few.

The package manager does not currently source the whole thing with
bash to get the EAPI, nor does it open the ebuild file at all for
metadata. You're talking doubling the number of file operations here,
and going from extremely good filesystem locality (which means very few
seeks) to jumping backwards and forwards all over the place.

This is basic stuff you really need to know before you can comment
sensibly on a discussion about package metadata.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: GLEP 55

[Rémi Cardona]

Ciaran McCreesh a écrit :
> The package manager does not currently source the whole thing with
> bash to get the EAPI, nor does it open the ebuild file at all for
> metadata. You're talking doubling the number of file operations here,
> and going from extremely good filesystem locality (which means very few
> seeks) to jumping backwards and forwards all over the place.

Yeah, grepping through the ebuild is just bound to get a massive 
performance hit, I don't have numbers but that just looks obvious.

Ciaran, what other pitfalls do you see for using one EAPI file per 
package (except for the broken compatibility, I know it's a big one) ?

> This is basic stuff you really need to know before you can comment
> sensibly on a discussion about package metadata.

Then, thanks for explaining those things :) We are learning stuff as we go.

-- 
Rémi Cardona
LRI, INRIA
remi.cardona@lri.fr
remi@gentoo.org
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Ciaran McCreesh]

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

On Tue, 10 Jun 2008 16:11:49 +0200
Rémi Cardona <remi@gentoo.org> wrote:
> Ciaran McCreesh a écrit :
> > The package manager does not currently source the whole thing with
> > bash to get the EAPI, nor does it open the ebuild file at all for
> > metadata. You're talking doubling the number of file operations
> > here, and going from extremely good filesystem locality (which
> > means very few seeks) to jumping backwards and forwards all over
> > the place.
> 
> Yeah, grepping through the ebuild is just bound to get a massive 
> performance hit, I don't have numbers but that just looks obvious.

No no. Doing the seek to open a file in a different directory and then
seeking back to your original directory over and over when otherwise
you'd be doing nice linear opens on adjacent inodes in a single
directory is where the performance hit is.

Paludis is pretty much seek bound in a lot of cases.

> Ciaran, what other pitfalls do you see for using one EAPI file per 
> package (except for the broken compatibility, I know it's a big one) ?

It's moving the relevant information further and further away from
where it's supposed to be. It doubles the number of files a developer
has to check in order to do simple ebuild maintenance.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: GLEP 55

[Rémi Cardona]

Ciaran McCreesh a écrit :
> No no. Doing the seek to open a file in a different directory and then
> seeking back to your original directory over and over when otherwise
> you'd be doing nice linear opens on adjacent inodes in a single
> directory is where the performance hit is.
> 
> Paludis is pretty much seek bound in a lot of cases.

Ok

> It's moving the relevant information further and further away from
> where it's supposed to be. It doubles the number of files a developer
> has to check in order to do simple ebuild maintenance.

I said one file per package, not per ebuild. It only doubles the number 
of files if there's only one ebuild in a given package :)

-- 
Rémi Cardona
LRI, INRIA
remi.cardona@lri.fr
remi@gentoo.org
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Vlastimil Babka]

Fernando J. Pereda wrote:
> 
> On 10 Jun 2008, at 15:33, Joe Peterson wrote:
> 
>> Luca Barbato wrote:
>>> Check if exists a line EAPI=*$, if does and the rest of the string
>>> matches an understood eapi, go on sourcing, otherwise ignore/mask it...
>>
>> And placing it out-of-band (like "# EAPI=...") avoids any sourcing
>> errors, makes parsing faster, etc.
> 
> No, it doesn't make parsing faster. Had you bothered to profile any 
> package manager you'd know that.

How much is parsing speed relevant when users in majority of cases 
already have the metadata cache from the rsync servers?
For devs (or users) hacking on an ebuild they have to source it anyway 
so the addition pre-parsing is negligible...

VB
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 55

[Joe Peterson]

Tiziano Müller wrote:
>>> And then how do we deal with EAPI 3, where the syntax changes again?
>> Portage (or whatever PM) reads the EAPI, determines it is 3, and goes
>> from there.  If you change the way you declare EAPI each time, yeah,
>> that's a problem, but I'm not sure why that would ne necessary.
> No, that is not the problem.
> 
> Example:
> In EAPI 42 we define that the package manager must provide a global function
> extract_depend_from_setup_py() such that it is callable at a global level
> in an ebuild like this
> 
> *snip start*
> 
> # Copyright 1999-2007 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
> # $Header: $
> 
> EAPI=42
> 
> DESCRIPTION="A library aiming to support agile and test-driven python
> development on various levels."
> SRC_URI="http://codespeak.net/download/${PN}/${P}.tar.gz"
> HOMEPAGE="http://codespeak.net/py/"
> KEYWORDS="~amd64 ~x86"
> SLOT="0"
> LICENSE="MIT"
> IUSE=""
> 
> extract_depend_from_setup_py
> 
> *snip end*
> 
> Now, a package manager (or a tool) not knowing EAPI 42 will fail when it
> tries to source the above ebuild to determine the EAPI version (as it is
> being currently done as far as I understood it) because
> extract_depend_from_setup_py is undefined.
> So it won't even be able to read out the EAPI.
> 
> With the EAPI in the filename tools now knowing EAPI-42 will either ignore
> the above foo-1.0.ebuild-42 or mask it because they may identify the
> EAPI-version without sourcing the ebuild.
> 
> And: No, just sourcing the ebuild and simply masking it because we can't
> source it is a no-go (since you're abusing error-handling as a case
> switch).

Agreed, and that's why I like the out-of-band solution better (i.e.
header line with "# EAPI=42".  No need for mangled filenames, and no
nead to actually source.

					-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] GLEP 55

[Bernd Steinhauser]

Joe Peterson schrieb:
> Ciaran McCreesh wrote:
>> On Mon, 09 Jun 2008 19:49:08 -0600
>> Joe Peterson <lavajoe@gentoo.org> wrote:
>>> Well, in general, if you rely on extensions changing every time a
>>> program cannot deal with a new feature of a file format, it would be
>>> quite crazy.  For example, if C programs had to start using ".c-2",
>>> ".c-3", etc., it would get ugly fast.
>> Which is why programs that use any major C feature introduced since
>> 1980 use the extension '.cc' or '.cpp'.
> 
> So why would not a one-time new extension (e.g. ".eb") do the trick,
> just like ".cc" works for C programs?  Unless you are talking about
> needing to specify the EAPI in the file if the more advanced features
> are to be used, but I see nothing wrong with that requirement - it's not
> much different than specifying a slot, keywords, whatever.
Because that is about the same "damage" (file ext. changes, people might
get confused etc.) with less capabilities.

>>> Also, it is easy to build EAPI checking into portage now, and when
>>> the requisite time passes, you only need to deal with situations
>>> where *very* old portage versions are still in use.  Since portage is
>>> typically the first thing the system upgrades after a sync, I don't
>>> see a big issue.  Or, if that is not acceptable, see my comment at
>>> the end about a one-time change to a new extension like ".eb".
>> You completely miss the point of the GLEP. We need new extensions
>> precisely because current package managers can't handle future EAPIs
>> cleanly, and we need to carry on using new extensions because otherwise
>> we restrict what future EAPIs can do.
> 
> No, I get that.  But once you develop the concept of an EAPI, the very
> next package manager version can be aware of it and check the EAPI of an
> ebuild.  If the ebuild specifies none, then it is old-style.  If it
> specifies one that is unknown or newer than what that package manager
> version knows it can handle, it can handle that case (ignore it or
> whatever).  I don't see why you need to keep bumping the
> filename/extension every time it changes from that point forward.
Because you can change the EAPI in a way that that may not work anymore.
Specifying the EAPI outside the actual ebuild is more flexible.
It doesn't have to be the file extension, but that is the obvious solution.

>>> But what users *really* don't care about is EAPIs, and this GLEP would
>>> expose that technical detail to them in a very blatent way.
>> Anyone who cares about ebuilds at a file level has to care about EAPIs.
> 
> Not really.  A typical user does not need to know about EAPIs at all,
> but he might want to peruse the portage tree to look for ebuilds.  He
> might also want to grep for KEYWORDS or whatever.  The user can delve
> into it as much as needed or desired, but if there are these mysterious
> EAPI numbers tacked onto the extensions, then it's an added complication
> that is not important to all users.
No, not really. If you have .txt, .txt-2, .text or .footext in a dir,
you would still realize, that those should be text files.
Of course, a future EAPI could be named .whatevercomestoyourmind, but
first, you can expect people to be smart enough to not do that and
second, you can still identify the packages, because they are still
named foo-version.whatevercomestoyourmind.

Bernd


-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: GLEP 55

[Duncan]

Bernd Steinhauser <gentoo@bernd-steinhauser.de> posted
484DF927.8010900@bernd-steinhauser.de, excerpted below, on  Tue, 10 Jun
2008 05:46:47 +0200:

> No, not really. If you have .txt, .txt-2, .text or .footext in a dir,
> you would still realize, that those should be text files.

The first three, yes, by long tradition, footext, not necessarily, as 
it's too ambiguous.  Just like the penisland dot com domain, which is 
read as pen-island and sells pens, BTW (at least last time I looked, 
after it came up as an example in a discussion similar to this), is that 
foo-text or foot-ext (the way I would read it by default) or foote-XT 
or...?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] GLEP 55

[Jan Kundrát]

Joe Peterson wrote:
>>> But what users *really* don't care about is EAPIs, and this GLEP would
>>> expose that technical detail to them in a very blatent way.
>> Anyone who cares about ebuilds at a file level has to care about EAPIs.
> 
> Not really.  A typical user does not need to know about EAPIs at all,
> but he might want to peruse the portage tree to look for ebuilds.  He
> might also want to grep for KEYWORDS or whatever.

If the user knows that keywords are set by the KEYWORDS variable, then
she must be familiar with the EAPI. The meaning of the KEYWORDS variable
is defined by the EAPI.

>>> Along those lines, as I've said before, migrating to a new extension,
>>> *one-time*, as a solution to this, although not optimal, would be far
>>> more satisfactory than introducing a series of ever-changing
>>> extensions.
>> No it won't. It means future EAPIs will be restricted to some
>> particular source format.
> 
> I assume you mean that EAPI needs to be in the file - again, is this
> bad?  Many file formats specify a file format version as part of the file.

Sure. If current EAPI specified that a sequence of four bytes starting
at offset  0x10 is a little-endian magic number that is used to identify
an EAPI, that'd be all we want. However, current format definition is
rather complex; there's nothing as simple as "read several bytes at some
offset and use them".

Cheers,
-jkt
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] GLEP 55

[Joe Peterson]

Jan Kundrát wrote:
> If the user knows that keywords are set by the KEYWORDS variable, then
> she must be familiar with the EAPI. The meaning of the KEYWORDS variable
> is defined by the EAPI.

But that's not really what I find objectionable.  There's no need to
make EAPI so special that it alters the file extension.  If EAPI is
accessible as part of the file or in metadata.xml, e.g., it still serves
this purpose well, and that info is exposed at the right level.

> Sure. If current EAPI specified that a sequence of four bytes starting
> at offset  0x10 is a little-endian magic number that is used to identify
> an EAPI, that'd be all we want. However, current format definition is
> rather complex; there's nothing as simple as "read several bytes at some
> offset and use them".

I would not suggest byte-level methods, no - these files are not binary.
 There are simple ways to parse text files to find the EAPI.  If it is
in the ebuild, putting it in the header (out-of-band) works.  If it is
in metadata, simply parsing XML works.

						-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] GLEP 55 (was: A few questions to our nominees)

[Robert Bridge]

On Tue, 10 Jun 2008 02:58:54 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> > Well, in general, if you rely on extensions changing every time a
> > program cannot deal with a new feature of a file format, it would be
> > quite crazy.  For example, if C programs had to start using ".c-2",
> > ".c-3", etc., it would get ugly fast.
> 
> Which is why programs that use any major C feature introduced since
> 1980 use the extension '.cc' or '.cpp'.

Except any program using .cc or .cpp for code is liable to break on
gcc, as they are C++ file extensions, and to the best of my (admittedly
limited knowledge) C and C++ are distinct languages...

So relying on the file extension seems to be a recipe for
misunderstanding. Why limit the functionality of the package manager to
rely on the file names? How do you protect the package manager from a
malicious ebuild masquerading under the wrong EAPI? Relying on the file
name for information is the kind of design decision we laugh at in
Windows, so why adopt it here?
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] GLEP 55 (was: A few questions to our nominees)

[Ciaran McCreesh]

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

On Tue, 10 Jun 2008 15:36:58 +0100
Robert Bridge <robert@robbieab.com> wrote:
> So relying on the file extension seems to be a recipe for
> misunderstanding. Why limit the functionality of the package manager
> to rely on the file names? How do you protect the package manager
> from a malicious ebuild masquerading under the wrong EAPI? Relying on
> the file name for information is the kind of design decision we laugh
> at in Windows, so why adopt it here?

There is no protection against malicious ebuilds. Malicious ebuilds
already run code as root when you install them. Being able to get an
ebuild run with the wrong EAPI is utterly irrelevant.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] A few questions to our nominees

[Luca Barbato]

Piotr Jaroszyński wrote:
> Hello,
> 
> looks like every nominee wants the council to be more technical so I
> have a few technical questions for you:
> 
> 1. GLEP54

Just for fun I took some of the ideas about alternative management of 
the issue and specified the features it makes it worth changing (better 
management and automated snapshot generation from the live ebuild).

http://dev.gentoo.org/~lu_zero/glep/liveebuild.rst

I'd like to see some comment on it (I put it in glep form just now so it 
isn't exactly perfect)

lu

-- 

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

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] A few questions to our nominees

[Ciaran McCreesh]

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

On Thu, 12 Jun 2008 11:05:01 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> Just for fun I took some of the ideas about alternative management of 
> the issue and specified the features it makes it worth changing
> (better management and automated snapshot generation from the live
> ebuild).
> 
> http://dev.gentoo.org/~lu_zero/glep/liveebuild.rst
> 
> I'd like to see some comment on it (I put it in glep form just now so
> it isn't exactly perfect)

* ordering for _pre is wrong.

* How are you planning to handle reinstalls? Should installing world
always reinstall live things? Never? Or what?

* How are live ebuilds selected by the package manager?

* What's the filename for "live ebuild for SVN trunk/"? What about
"live ebuild for SVN branches/0.26/"?

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] A few questions to our nominees

[Luca Barbato]

Ciaran McCreesh wrote:
> On Thu, 12 Jun 2008 11:05:01 +0200
> Luca Barbato <lu_zero@gentoo.org> wrote:
>> Just for fun I took some of the ideas about alternative management of 
>> the issue and specified the features it makes it worth changing
>> (better management and automated snapshot generation from the live
>> ebuild).
>>
>> http://dev.gentoo.org/~lu_zero/glep/liveebuild.rst
>>
>> I'd like to see some comment on it (I put it in glep form just now so
>> it isn't exactly perfect)
> 
> * ordering for _pre is wrong.

hm?

> * How are you planning to handle reinstalls? Should installing world
> always reinstall live things? Never? Or what?

depends on the other ebuilds

> * How are live ebuilds selected by the package manager?

live ebuilds gets considered as preN+1 for any purpose.

> * What's the filename for "live ebuild for SVN trunk/"? What about

foo-${version inside trunk}.live?

> "live ebuild for SVN branches/0.26/"?

foo-0.26.live?

What is inside the template is just concern of the ebuild writer. I 
suggest to use the same version as marked in the configure or other 
version value the release will get once upstream decides to release.

lu

-- 

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

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] A few questions to our nominees

[Ciaran McCreesh]

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

On Thu, 12 Jun 2008 21:40:28 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> > * ordering for _pre is wrong.
> 
> hm?

foo-0.26-live would become foo-0.26_pre1, which would be < 0.26. This
is clearly wrong.

> > * How are you planning to handle reinstalls? Should installing world
> > always reinstall live things? Never? Or what?
> 
> depends on the other ebuilds

More specifically?

> > * How are live ebuilds selected by the package manager?
> 
> live ebuilds gets considered as preN+1 for any purpose.

So you're saying they *always* get reinstalled as a new version if
they're part of the dep tree?

> > * What's the filename for "live ebuild for SVN trunk/"? What about
> 
> foo-${version inside trunk}.live?

And when trunk is unversioned?

> > "live ebuild for SVN branches/0.26/"?
> 
> foo-0.26.live?

Orders incorrectly when 0.26.1 has been released.

> What is inside the template is just concern of the ebuild writer. I 
> suggest to use the same version as marked in the configure or other 
> version value the release will get once upstream decides to release.

There's no way of getting the desired effect with current dep specs.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] A few questions to our nominees

[Luca Barbato]

Ciaran McCreesh wrote:
> On Thu, 12 Jun 2008 21:40:28 +0200
> Luca Barbato <lu_zero@gentoo.org> wrote:
>>> * ordering for _pre is wrong.
>> hm?
> 
> foo-0.26-live would become foo-0.26_pre1, which would be < 0.26. This
> is clearly wrong.

No, it is correct and what you want. Upstream is aiming for 0.26, once 
0.26 gets in portage you want to update to the release.

>>> * How are you planning to handle reinstalls? Should installing world
>>> always reinstall live things? Never? Or what?
>> depends on the other ebuilds
> 
> More specifically?

the live ebuild act as template for a autogenerated _pre, if there is 
something higher than _pre that one will be picked.

>>> * How are live ebuilds selected by the package manager?
>> live ebuilds gets considered as preN+1 for any purpose.
> 
> So you're saying they *always* get reinstalled as a new version if
> they're part of the dep tree?

only on -e since you do not have the live template evaluated again.

>>> * What's the filename for "live ebuild for SVN trunk/"? What about
>> foo-${version inside trunk}.live?
> 
> And when trunk is unversioned?

Upstream has an issue, still you know which is the version they aim.

>>> "live ebuild for SVN branches/0.26/"?
>> foo-0.26.live?
> 
> Orders incorrectly when 0.26.1 has been released.

no.

>> What is inside the template is just concern of the ebuild writer. I 
>> suggest to use the same version as marked in the configure or other 
>> version value the release will get once upstream decides to release.
> 
> There's no way of getting the desired effect with current dep specs.

Your comment seems unrelated to the text.

Anyway pkgcore and portage devs, I'd like your opinion on this point.

lu

-- 

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

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] A few questions to our nominees

[Fernando J. Pereda]

On 13 Jun 2008, at 10:43, Luca Barbato wrote:
>>>> * What's the filename for "live ebuild for SVN trunk/"? What about
>>> foo-${version inside trunk}.live?
>> And when trunk is unversioned?
>
> Upstream has an issue, still you know which is the version they aim.

Wrong. Your GLEP has an issue because it isn't able to cover a real- 
world case. See the pu branch in Git.

- ferdy

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] A few questions to our nominees

[Ciaran McCreesh]

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

On Fri, 13 Jun 2008 10:43:39 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > On Thu, 12 Jun 2008 21:40:28 +0200
> > Luca Barbato <lu_zero@gentoo.org> wrote:
> >>> * ordering for _pre is wrong.
> >> hm?
> > 
> > foo-0.26-live would become foo-0.26_pre1, which would be < 0.26.
> > This is clearly wrong.
> 
> No, it is correct and what you want. Upstream is aiming for 0.26,
> once 0.26 gets in portage you want to update to the release.

A lot of projects work like this:

* trunk/ is current development, and is ahead of any release.

* branches/0.26/ is forked from trunk/ when 0.26 is released, and is
equal to or ahead of any 0.26 release.

How does your proposal handle this?

> >>> * How are you planning to handle reinstalls? Should installing
> >>> world always reinstall live things? Never? Or what?
> >> depends on the other ebuilds
> > 
> > More specifically?
> 
> the live ebuild act as template for a autogenerated _pre, if there is 
> something higher than _pre that one will be picked.

So you install foo-1.2-live. The package manager installs this as
foo-1.2_pre1. Then, foo-1.2-live becomes foo-1.2_pre2.

Which has two issues:

* It means whenever you install foo-1.2-live, there will always be a
newer version, and the package manager will always select it for
upgrades. Is this really desired behaviour?

* It means the package manager somehow has to keep track of what pre to
substitute in. How does it do this?

> 
> >>> * How are live ebuilds selected by the package manager?
> >> live ebuilds gets considered as preN+1 for any purpose.
> > 
> > So you're saying they *always* get reinstalled as a new version if
> > they're part of the dep tree?
> 
> only on -e since you do not have the live template evaluated again.

So when are templates evaluated?

> >>> * What's the filename for "live ebuild for SVN trunk/"? What about
> >> foo-${version inside trunk}.live?
> > 
> > And when trunk is unversioned?
> 
> Upstream has an issue, still you know which is the version they aim.

Again, no. It's fairly common for unversioned trunk where upstream
don't yet know if it'll be released as an x release, an x.y release or
an x.y.z release.

> >>> "live ebuild for SVN branches/0.26/"?
> >> foo-0.26.live?
> > 
> > Orders incorrectly when 0.26.1 has been released.
> 
> no.

Yup, because your 0.26 branch will be equal to or ahead of 0.26.1, but
0.26.live will order as less than 0.26.

> Anyway pkgcore and portage devs, I'd like your opinion on this point.

What, the gaping holes I've pointed out aren't enough?

-- 
Ciaran McCreesh

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

[gentoo-dev] Re: A few questions to our nominees

[Tiziano Müller]

Ciaran McCreesh wrote:

> On Fri, 13 Jun 2008 10:43:39 +0200
> Luca Barbato <lu_zero@gentoo.org> wrote:
>> Ciaran McCreesh wrote:
>> > On Thu, 12 Jun 2008 21:40:28 +0200
>> > Luca Barbato <lu_zero@gentoo.org> wrote:
>> >>> * ordering for _pre is wrong.
>> >> hm?
>> > 
>> > foo-0.26-live would become foo-0.26_pre1, which would be < 0.26.
>> > This is clearly wrong.
>> 
>> No, it is correct and what you want. Upstream is aiming for 0.26,
>> once 0.26 gets in portage you want to update to the release.
> 
> A lot of projects work like this:
> 
> * trunk/ is current development, and is ahead of any release.
> 
> * branches/0.26/ is forked from trunk/ when 0.26 is released, and is
> equal to or ahead of any 0.26 release.
> 
> How does your proposal handle this?

s/_pre/_p ?


-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: A few questions to our nominees

[Ciaran McCreesh]

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

On Fri, 13 Jun 2008 11:14:49 +0200
Tiziano Müller <dev-zero@gentoo.org> wrote:
> > How does your proposal handle this?
> 
> s/_pre/_p ?

Collides with existing use of _p. It means you can't use _p for manual
snapshots if there's also a live ebuild, since foo-1.2_p3 (from a live
ebuild) would incorrectly order less than foo-1.2_p20080613 (from a
manual snapshot).

-- 
Ciaran McCreesh

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

[gentoo-dev] Re: A few questions to our nominees

[Tiziano Müller]

Ciaran McCreesh wrote:

> On Fri, 13 Jun 2008 10:43:39 +0200
> Luca Barbato <lu_zero@gentoo.org> wrote:
>> Ciaran McCreesh wrote:
>> > On Thu, 12 Jun 2008 21:40:28 +0200
>> > Luca Barbato <lu_zero@gentoo.org> wrote:
>> >>> * ordering for _pre is wrong.
>> >> hm?
>> > 
>> > foo-0.26-live would become foo-0.26_pre1, which would be < 0.26.
>> > This is clearly wrong.
>> 
>> No, it is correct and what you want. Upstream is aiming for 0.26,
>> once 0.26 gets in portage you want to update to the release.
> 
> A lot of projects work like this:
> 
> * trunk/ is current development, and is ahead of any release.
> 
> * branches/0.26/ is forked from trunk/ when 0.26 is released, and is
> equal to or ahead of any 0.26 release.
> 
> How does your proposal handle this?
> 
>> >>> * How are you planning to handle reinstalls? Should installing
>> >>> world always reinstall live things? Never? Or what?
>> >> depends on the other ebuilds
>> > 
>> > More specifically?
>> 
>> the live ebuild act as template for a autogenerated _pre, if there is
>> something higher than _pre that one will be picked.
> 
> So you install foo-1.2-live. The package manager installs this as
> foo-1.2_pre1. Then, foo-1.2-live becomes foo-1.2_pre2.
> 
> Which has two issues:
> 
> * It means whenever you install foo-1.2-live, there will always be a
> newer version, and the package manager will always select it for
> upgrades. Is this really desired behaviour?
> 
> * It means the package manager somehow has to keep track of what pre to
> substitute in. How does it do this?

@lu_zero: I don't think we can get away without having the pm know what a
live-ebuild exactly is and when to re-install it.
(Just in case you were thinking of letting the pm auto-masking/unmasking
foo_p${value+1}: this would be hackish and ugly).


-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: A few questions to our nominees

[Luca Barbato]

Tiziano Müller wrote:
> @lu_zero: I don't think we can get away without having the pm know what a
> live-ebuild exactly is and when to re-install it.

a live ebuild is a template, every time it has to be evaluated it acts 
as a normal ebuild with the version mentioned and _preN+1 postponed, 
preN is the highest preN present, if present.

> (Just in case you were thinking of letting the pm auto-masking/unmasking
> foo_p${value+1}: this would be hackish and ugly).

Uh?


-- 

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

-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: Re: A few questions to our nominees

[Tiziano Müller]

Luca Barbato wrote:

> Tiziano Müller wrote:
>> @lu_zero: I don't think we can get away without having the pm know what a
>> live-ebuild exactly is and when to re-install it.
> 
> a live ebuild is a template, every time it has to be evaluated it acts
> as a normal ebuild with the version mentioned and _preN+1 postponed,
> preN is the highest preN present, if present.
Sorry, but I don't want to re-install a snapshot every time I do a world
update. And I also don't want to manually mask/unmask the live ebuilds.
I either want to be able to specify a time interval after which live ebuilds
should be refetched or being able to manually re-install them (second use
case is trivial).

>> (Just in case you were thinking of letting the pm auto-masking/unmasking
>> foo_p${value+1}: this would be hackish and ugly).
> 
> Uh?
> 

Ok, a solution to the problem for above (automatically re-install a live
ebuild after a given time) would probably be to let the pm write a
package.mask file which masks foo-1.2_pre${NUMBER+1} until the given time
is elapsed and then change to mask to match foo-1.2_pre${NUMBER+2} to
trigger re-installation (therefore "auto-masking/unmasking").


-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Re: A few questions to our nominees

[Luca Barbato]

Tiziano Müller wrote:
> Luca Barbato wrote:
> 
>> Tiziano Müller wrote:
>>> @lu_zero: I don't think we can get away without having the pm know what a
>>> live-ebuild exactly is and when to re-install it.
>> a live ebuild is a template, every time it has to be evaluated it acts
>> as a normal ebuild with the version mentioned and _preN+1 postponed,
>> preN is the highest preN present, if present.
> Sorry, but I don't want to re-install a snapshot every time I do a world
> update. And I also don't want to manually mask/unmask the live ebuilds.

This part of the behavior, when the update is triggered, isn't specified 
quite well, I'd trigger it when the cache gets invalidated, but I'm open 
to alternatives.

> I either want to be able to specify a time interval after which live ebuilds
> should be refetched or being able to manually re-install them (second use
> case is trivial).

Right.

> Ok, a solution to the problem for above (automatically re-install a live
> ebuild after a given time) would probably be to let the pm write a
> package.mask file which masks foo-1.2_pre${NUMBER+1} until the given time
> is elapsed and then change to mask to match foo-1.2_pre${NUMBER+2} to
> trigger re-installation (therefore "auto-masking/unmasking").

I see, that's ugly indeed.

lu

-- 

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

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Re: A few questions to our nominees

[Jorge Manuel B. S. Vicetto]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

What's the need for a GLEP covering "live" ebuilds and what's wrong with
- -9999 ebuilds? I made myself that question when GLEP54 was submitted and
during the initial discussion. At that time, I wasn't convinced of the
need for such a GLEP. Now I think it can be very useful.
Why did I change my mind? Let's have a concrete use case.

Updating the live ebuilds for compiz, can be a mess. If the ebuilds
aren't updated in the correct order, the process will fail and leave
users wondering why it failed. What we need is a way to ask the PM to
update compiz-fusion and or fusion-icon and all its "live" deps.

Currently, users with Portage have to run something like:
~  emerge -av1 compiz compiz-bcop compiz-fusion-plugins-main \
~    compiz-fusion-plugins-extra compiz-fusion-plugins-unsupported \
~    emerald emerald-themes libcompizconfig compizconfig-python \
~    ccsm compizconfig-backend-gconf compizconfig-backend-kconfig \
~    compiz-fusion fusion-icon

Those using paludis need just to run[1]:
~  paludis -pi1 compiz-fusion --dl-reinstall-scm always --compact \
~    --show-reasons none

[1] - I don't run paludis myself. That command is what some paludis
users run to update the compiz ebuilds.

The problem with the -9999 ebuilds is that we need to force manually the
reinstalls and that the PM isn't able to determine if a dep needs to be
updated or not from the ebuild revision.

Tiziano Müller wrote:
| Luca Barbato wrote:
|
|> Tiziano Müller wrote:
|>> @lu_zero: I don't think we can get away without having the pm know
what a
|>> live-ebuild exactly is and when to re-install it.
|> a live ebuild is a template, every time it has to be evaluated it acts
|> as a normal ebuild with the version mentioned and _preN+1 postponed,
|> preN is the highest preN present, if present.
| Sorry, but I don't want to re-install a snapshot every time I do a world
| update. And I also don't want to manually mask/unmask the live ebuilds.
| I either want to be able to specify a time interval after which live
ebuilds
| should be refetched or being able to manually re-install them (second use
| case is trivial).
|

So, running a reinstall with a world update is not desirable and having
to manually mask/unmask live ebuilds can also be a mess.
Having a method that lets the user choose to reinstall all the live
ebuilds every N days is an interesting option. Having a method that lets
the user choose that the PM should check the scm tree and update the
package if there's a new revision would be even better.
But for most cases, if we define a method to identify "live" ebuilds so
that the PM can implement a "--dl-reinstall-scm" like option, would be
"good enough" or at least a "very good start".

One option that might be interesting to avoid having the PM update *all*
live deps, would be to have an option to run the update for packages
inside a set. In this case, for example, I could just add all the compiz
packages to a set and not worry about the PM updating also all the live
kde packages.

Another case where having a method to let PMs identify "live" ebuilds is
important is for running QA scripts like repoman or pcheck.
Instead of having pcheck complain about dropped keywords for version
9999, I would like to have pcheck complain about "live" ebuilds with
keywords. Not all "live" trees are unstable and thus some might not like
this change. However, if a PM is able to determine "live" ebuilds, it
might be easier to have alternative tests that allow testing for dropped
keywords or for the existence of keywords just for "live" ebuilds.

- --
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / SPARC / KDE
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkhTsU8ACgkQcAWygvVEyAK5JwCfQlflTUNi9hDcUgwgxgAyUbS6
lakAoJhyQG4KsnyfRJez6edhuKQmVVOL
=y7PF
-----END PGP SIGNATURE-----
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Re: A few questions to our nominees

[Patrick Lauer]

On Saturday 14 June 2008 11:53:51 Jorge Manuel B. S. Vicetto wrote:
> What's the need for a GLEP covering "live" ebuilds and what's wrong with
> -9999 ebuilds? I made myself that question when GLEP54 was submitted and
> during the initial discussion. At that time, I wasn't convinced of the
> need for such a GLEP. Now I think it can be very useful.
> Why did I change my mind? Let's have a concrete use case.
>
> Updating the live ebuilds for compiz, can be a mess. If the ebuilds
> aren't updated in the correct order, the process will fail and leave
> users wondering why it failed. What we need is a way to ask the PM to
> update compiz-fusion and or fusion-icon and all its "live" deps.

Ok, here's a silly idea - 

tag the ebuilds with metadata. We already have RESTRICT, why not add a "LIVE" 
variable. The package manager can then treat all ebuilds with that tag 
differently. Scripts can find them easily. It is forwards and backwards 
compatible and doesn't cause any user-visible changes.

Portage 2.2 and others support sets, portage 2.2 even supports dynamic sets 
like the "@preserved-rebuild". Shouldn't be that hard to add a "live-ebuilds" 
dynamic set.
(Comments on the feasibility of my idea from portage people appreciated)

> Currently, users with Portage have to run something like:
> ~  emerge -av1 compiz compiz-bcop compiz-fusion-plugins-main \
> ~    compiz-fusion-plugins-extra compiz-fusion-plugins-unsupported \
> ~    emerald emerald-themes libcompizconfig compizconfig-python \
> ~    ccsm compizconfig-backend-gconf compizconfig-backend-kconfig \
> ~    compiz-fusion fusion-icon

That is the situation where you really love the sets in portage 2.2 - by 
default portage will re-merge every ebuild from a set when run as "emerge 
@your-custom-set". Now the overlay maintainer just has to provide the sets 
with the overlay and users are happy.

> The problem with the -9999 ebuilds is that we need to force manually the
> reinstalls and that the PM isn't able to determine if a dep needs to be
> updated or not from the ebuild revision.

If you use sets the updating part is easy, and in situations like emerge -e 
world you want to update them anyway.

> So, running a reinstall with a world update is not desirable and having
> to manually mask/unmask live ebuilds can also be a mess.

I don't follow - if you want to update everything everything gets upgraded.

What you seem to want is a way to make certain revisions "sticky" so that they 
don't get updated, that would need something like a "package.revisions" file 
like package.keywords containing "category/package revision" lines.

> Having a method that lets the user choose to reinstall all the live
> ebuilds every N days is an interesting option. Having a method that lets
> the user choose that the PM should check the scm tree and update the
> package if there's a new revision would be even better.

I think that can be easily done if there's an easy way to pull the installed 
revision and currently available. The last discussions about that stalled 
without reaching agreement.

> But for most cases, if we define a method to identify "live" ebuilds so
> that the PM can implement a "--dl-reinstall-scm" like option, would be
> "good enough" or at least a "very good start".

I agree

> Another case where having a method to let PMs identify "live" ebuilds is
> important is for running QA scripts like repoman or pcheck.
> Instead of having pcheck complain about dropped keywords for version
> 9999, I would like to have pcheck complain about "live" ebuilds with
> keywords. Not all "live" trees are unstable and thus some might not like
> this change. However, if a PM is able to determine "live" ebuilds, it
> might be easier to have alternative tests that allow testing for dropped
> keywords or for the existence of keywords just for "live" ebuilds.

That's what metadata is there for. And ebuilds don't mind carrying a bit 
more ... after all it's just one line of text.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Re: A few questions to our nominees

[Bernd Steinhauser]

Patrick Lauer schrieb:
> On Saturday 14 June 2008 11:53:51 Jorge Manuel B. S. Vicetto wrote:
>> What's the need for a GLEP covering "live" ebuilds and what's wrong with
>> -9999 ebuilds? I made myself that question when GLEP54 was submitted and
>> during the initial discussion. At that time, I wasn't convinced of the
>> need for such a GLEP. Now I think it can be very useful.
>> Why did I change my mind? Let's have a concrete use case.
>>
>> Updating the live ebuilds for compiz, can be a mess. If the ebuilds
>> aren't updated in the correct order, the process will fail and leave
>> users wondering why it failed. What we need is a way to ask the PM to
>> update compiz-fusion and or fusion-icon and all its "live" deps.
> 
> Ok, here's a silly idea - 
> 
> tag the ebuilds with metadata. We already have RESTRICT, why not add a "LIVE" 
> variable. The package manager can then treat all ebuilds with that tag 
> differently. Scripts can find them easily. It is forwards and backwards 
> compatible and doesn't cause any user-visible changes.
> 
> Portage 2.2 and others support sets, portage 2.2 even supports dynamic sets 
> like the "@preserved-rebuild". Shouldn't be that hard to add a "live-ebuilds" 
> dynamic set.
> (Comments on the feasibility of my idea from portage people appreciated)
> 
>> Currently, users with Portage have to run something like:
>> ~  emerge -av1 compiz compiz-bcop compiz-fusion-plugins-main \
>> ~    compiz-fusion-plugins-extra compiz-fusion-plugins-unsupported \
>> ~    emerald emerald-themes libcompizconfig compizconfig-python \
>> ~    ccsm compizconfig-backend-gconf compizconfig-backend-kconfig \
>> ~    compiz-fusion fusion-icon
> 
> That is the situation where you really love the sets in portage 2.2 - by 
> default portage will re-merge every ebuild from a set when run as "emerge 
> @your-custom-set". Now the overlay maintainer just has to provide the sets 
> with the overlay and users are happy.
> 
>> The problem with the -9999 ebuilds is that we need to force manually the
>> reinstalls and that the PM isn't able to determine if a dep needs to be
>> updated or not from the ebuild revision.
> 
> If you use sets the updating part is easy, and in situations like emerge -e 
> world you want to update them anyway.
> 
>> So, running a reinstall with a world update is not desirable and having
>> to manually mask/unmask live ebuilds can also be a mess.
> 
> I don't follow - if you want to update everything everything gets upgraded.
> 
> What you seem to want is a way to make certain revisions "sticky" so that they 
> don't get updated, that would need something like a "package.revisions" file 
> like package.keywords containing "category/package revision" lines.
> 
>> Having a method that lets the user choose to reinstall all the live
>> ebuilds every N days is an interesting option. Having a method that lets
>> the user choose that the PM should check the scm tree and update the
>> package if there's a new revision would be even better.
> 
> I think that can be easily done if there's an easy way to pull the installed 
> revision and currently available. The last discussions about that stalled 
> without reaching agreement.
> 
>> But for most cases, if we define a method to identify "live" ebuilds so
>> that the PM can implement a "--dl-reinstall-scm" like option, would be
>> "good enough" or at least a "very good start".
> 
> I agree
> 
>> Another case where having a method to let PMs identify "live" ebuilds is
>> important is for running QA scripts like repoman or pcheck.
>> Instead of having pcheck complain about dropped keywords for version
>> 9999, I would like to have pcheck complain about "live" ebuilds with
>> keywords. Not all "live" trees are unstable and thus some might not like
>> this change. However, if a PM is able to determine "live" ebuilds, it
>> might be easier to have alternative tests that allow testing for dropped
>> keywords or for the existence of keywords just for "live" ebuilds.
> 
> That's what metadata is there for. And ebuilds don't mind carrying a bit 
> more ... after all it's just one line of text.
So, what you want to do is to read every ebuild, if you want to find all 
live ebuilds?
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Re: A few questions to our nominees

[Patrick Lauer]

On Saturday 14 June 2008 14:11:12 Bernd Steinhauser wrote:
> > That's what metadata is there for. And ebuilds don't mind carrying a bit
> > more ... after all it's just one line of text.
>
> So, what you want to do is to read every ebuild, if you want to find all
> live ebuilds?

Metadata cache. It's there for a reason.


-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Re: A few questions to our nominees

[Bernd Steinhauser]

Patrick Lauer schrieb:
> On Saturday 14 June 2008 14:11:12 Bernd Steinhauser wrote:
>>> That's what metadata is there for. And ebuilds don't mind carrying a bit
>>> more ... after all it's just one line of text.
>> So, what you want to do is to read every ebuild, if you want to find all
>> live ebuilds?
> 
> Metadata cache. It's there for a reason.
> 
> 
Still a lot slower.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Re: A few questions to our nominees

[Bernd Steinhauser]

Patrick Lauer schrieb:
> On Saturday 14 June 2008 14:11:12 Bernd Steinhauser wrote:
>>> That's what metadata is there for. And ebuilds don't mind carrying a bit
>>> more ... after all it's just one line of text.
>> So, what you want to do is to read every ebuild, if you want to find all
>> live ebuilds?
> 
> Metadata cache. It's there for a reason.
> 
> 
Besides, what will you do to determine if an installed ebuild is a live one?
Go through the metadata cache for the non-installed stuff?
Go through these ebuilds?

Sounds like fun...
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: A few questions to our nominees

[Ryan Hill]

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

On Sat, 14 Jun 2008 12:32:22 +0000
Patrick Lauer <bugs@dev.gentooexperimental.org> wrote:

> Ok, here's a silly idea - 
> 
> tag the ebuilds with metadata. We already have RESTRICT, why not add
> a "LIVE" variable. The package manager can then treat all ebuilds
> with that tag differently. Scripts can find them easily.

Or we could create a scm suffix and not have to parse ebuilds to get
that info.  As an added bonus live ebuilds are instantly identifiable
and can use proper versions numbers instead of 9999.

> Portage 2.2 and others support sets, portage 2.2 even supports
> dynamic sets like the "@preserved-rebuild". Shouldn't be that hard to
> add a "live-ebuilds" dynamic set.

Just as easy with -scm.

> (Comments on the feasibility of my idea from portage people
> appreciated)
> 
> > Currently, users with Portage have to run something like:
> > ~  emerge -av1 compiz compiz-bcop compiz-fusion-plugins-main \
> > ~    compiz-fusion-plugins-extra compiz-fusion-plugins-unsupported \
> > ~    emerald emerald-themes libcompizconfig compizconfig-python \
> > ~    ccsm compizconfig-backend-gconf compizconfig-backend-kconfig \
> > ~    compiz-fusion fusion-icon
> 
> That is the situation where you really love the sets in portage 2.2 -
> by default portage will re-merge every ebuild from a set when run as
> "emerge @your-custom-set". Now the overlay maintainer just has to
> provide the sets with the overlay and users are happy.

His problem is updating the packages in a specific order.  I don't
remember sets preserving merge order, but then again I wasn't looking.

> > Having a method that
> > lets the user choose that the PM should check the scm tree and
> > update the package if there's a new revision would be even better.
> 
> I think that can be easily done if there's an easy way to pull the
> installed revision and currently available. The last discussions
> about that stalled without reaching agreement.

I could have sworn subversion.eclass already did this but now I can't
find the code.  I might have seen it in an overlay or on the forums.


-- 
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: A few questions to our nominees

[Duncan]

Ryan Hill <dirtyepic@gentoo.org> posted
20080614090426.17d3c327@halo.dirtyepic.sk.ca, excerpted below, on  Sat, 14
Jun 2008 09:04:26 -0600:

>> > Having a method that
>> > lets the user choose that the PM should check the scm tree and update
>> > the package if there's a new revision would be even better.
>> 
>> I think that can be easily done if there's an easy way to pull the
>> installed revision and currently available. The last discussions about
>> that stalled without reaching agreement.
> 
> I could have sworn subversion.eclass already did this but now I can't
> find the code.  I might have seen it in an overlay or on the forums.

Isn't it subversion itself that does this, based on local and remote 
repository revision numbers?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Re: A few questions to our nominees

[Marius Mauch]

On Sat, 14 Jun 2008 12:32:22 +0000
Patrick Lauer <bugs@dev.gentooexperimental.org> wrote:

> Portage 2.2 and others support sets, portage 2.2 even supports
> dynamic sets like the "@preserved-rebuild". Shouldn't be that hard to
> add a "live-ebuilds" dynamic set.
> (Comments on the feasibility of my idea from portage people
> appreciated)

Should be simple if there is a definite way to determine if an ebuild
is a 'live' eubild or not, wether that's by examining the
name/category/version/metadata/external list/moon phase doesn't really
matter (well, moon phase might complicate it a bit ;)

Marius
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Re: A few questions to our nominees

[Luca Barbato]

Jorge Manuel B. S. Vicetto wrote:
> Those using paludis need just to run[1]:
> ~  paludis -pi1 compiz-fusion --dl-reinstall-scm always --compact \
> ~    --show-reasons none

and what about

# emerge @compiz [1]

Simpler isn't it?

Or

# emaint -r world[2]
# emerge -u compiz-fusion

[1] you you can do that right now.
[2] possible way to trigger regeneration, extended to sets if interesting.


> So, running a reinstall with a world update is not desirable and having
> to manually mask/unmask live ebuilds can also be a mess.

Agreed.

> Having a method that lets the user choose to reinstall all the live
> ebuilds every N days is an interesting option. Having a method that lets
> the user choose that the PM should check the scm tree and update the
> package if there's a new revision would be even better.

so something like

#emerge -uL compiz-fusion is what you'd like better.

> One option that might be interesting to avoid having the PM update *all*
> live deps, would be to have an option to run the update for packages
> inside a set. In this case, for example, I could just add all the compiz
> packages to a set and not worry about the PM updating also all the live
> kde packages.

right now you can add all the compiz packages to a set and just issue 
and emerge @compiz and archive what you want ^^

> Another case where having a method to let PMs identify "live" ebuilds is
> important is for running QA scripts like repoman or pcheck.
> Instead of having pcheck complain about dropped keywords for version
> 9999, I would like to have pcheck complain about "live" ebuilds with
> keywords. Not all "live" trees are unstable and thus some might not like
> this change. However, if a PM is able to determine "live" ebuilds, it
> might be easier to have alternative tests that allow testing for dropped
> keywords or for the existence of keywords just for "live" ebuilds.

Agreed.

lu

-- 

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

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] A few questions to our nominees

[Brian Harring]

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

On Fri, Jun 13, 2008 at 10:43:39AM +0200, Luca Barbato wrote:
> Anyway pkgcore and portage devs, I'd like your opinion on this point.

Custom repository is how I intended to implement this; the upshot of 
the version translation is that the resultant vdb version is managable 
by any PM, regardless if they support -live, which 'generated' the 
ebuild.

Presuming svn python bindings aren't as sucky as I recall, tempted to 
take a thwack at it over the weekend.

One thing that would need ironing out for such a proposal is how to 
mark in the template metadata variation dependant upon vcs exceeding a 
certain level- example would be,

<  revno 300
RDEPEND='=dev-lang/python-2.4*'

>= revno 300
RDEPEND='>=dev-lang/python-2.5'

That... gets tricky.  I can think of hacks for it, but none I like.  
Alternatively, if there was a way to have seperate templates that are 
selected dependant upon the desired rev, it becomes possible.

One other thing that needs discussion imo, is how such a scheme would 
work for non integer based revnos- git for example, which is reliant 
on a hash (just the hash, afaik).

Either way, I tend to view it as having a fair bit more control then 
the -scm proposal, although needs fleshing out a bit.

~harring

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

Re: [gentoo-dev] A few questions to our nominees

[Ciaran McCreesh]

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

On Fri, 13 Jun 2008 04:14:38 -0700
Brian Harring <ferringb@gmail.com> wrote:
> One other thing that needs discussion imo, is how such a scheme would 
> work for non integer based revnos- git for example, which is reliant 
> on a hash (just the hash, afaik).

Neither Luca's proposal nor -scm even attempts to address anything to
do with upstream revisions.

Whilst doing so would be useful, it's considerably more work. There's
another proposal floating around that lets -scm be extended to deal
with upstream revisions too, but from an amount-of-work perspective
it's highly unlikely that Portage will be able to deliver that stage of
it any time soon -- the -scm proposal is designed to fit in nicely with
the way ebuilds currently handle live packages, whilst not requiring
much effort to implement.

Being realistic here, -scm is something that's deliverable and useful
in a relatively short timeframe, but extending it to upstream-revision
awareness isn't.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] A few questions to our nominees

[Luca Barbato]

Brian Harring wrote:
> Custom repository is how I intended to implement this; the upshot of 
> the version translation is that the resultant vdb version is managable 
> by any PM, regardless if they support -live, which 'generated' the 
> ebuild.
> 
> Presuming svn python bindings aren't as sucky as I recall, tempted to 
> take a thwack at it over the weekend.

Would be great =)

> One thing that would need ironing out for such a proposal is how to 
> mark in the template metadata variation dependant upon vcs exceeding a 
> certain level- example would be,

> <  revno 300
> RDEPEND='=dev-lang/python-2.4*'
> 
>> = revno 300
> RDEPEND='>=dev-lang/python-2.5'

That would be quite tricky and I'm not sure how many time it will be 
useful since we don't know the future this well ^^;
I'd leave this part out for now.

> One other thing that needs discussion imo, is how such a scheme would 
> work for non integer based revnos- git for example, which is reliant 
> on a hash (just the hash, afaik).

The revision has to be stored inside the generated ebuild so all you 
need to have is:

- a way to know the revision you are checking out
- a way to store such revision withing the ebuild

lu

-- 

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

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] A few questions to our nominees

[Ciaran McCreesh]

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

On Fri, 13 Jun 2008 13:32:47 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> The revision has to be stored inside the generated ebuild so all you 
> need to have is:
> 
> - a way to know the revision you are checking out
> - a way to store such revision withing the ebuild

- a way of doing this cheaply so resolution doesn't take half an hour
when you have kde-scm installed.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] A few questions to our nominees

[Marius Mauch]

On Thu, 12 Jun 2008 11:05:01 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:

> Piotr Jaroszyński wrote:
> > Hello,
> > 
> > looks like every nominee wants the council to be more technical so I
> > have a few technical questions for you:
> > 
> > 1. GLEP54
> 
> Just for fun I took some of the ideas about alternative management of 
> the issue and specified the features it makes it worth changing
> (better management and automated snapshot generation from the live
> ebuild).
> 
> http://dev.gentoo.org/~lu_zero/glep/liveebuild.rst
> 
> I'd like to see some comment on it (I put it in glep form just now so
> it isn't exactly perfect)

Ignoring possible semantic issues for the moment, I'd be against this
simply because it would require the PM to be aware of the current
revision of the repository and to transform it into a integer value
(trivial for SVN, not so trivial for CVS for example). Which in turn
either means that the PM has to internally support the SCMs or support
some new phase functions to extract the revision.
Plus it has similar (unstated) transition issues as GLEP-54, just avoids
a new comparison algorithm and the CPV vs. atom issue.

Marius
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: A few questions to our nominees

[Ryan Hill]

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

On Fri, 13 Jun 2008 13:35:52 +0200
Marius Mauch <genone@gentoo.org> wrote:

> Ignoring possible semantic issues for the moment, I'd be against this
> simply because it would require the PM to be aware of the current
> revision of the repository and to transform it into a integer value
> (trivial for SVN, not so trivial for CVS for example). Which in turn
> either means that the PM has to internally support the SCMs or support
> some new phase functions to extract the revision.

I'm confused.  If I have a gcc-4.4.0.live ebuild which checks out rev.
136737, after the merge do I have gcc-4.4.0_pre136737
or gcc-4.4.0_pre1 (and gcc-4.4.0_pre2 next time I merge it, etc)
installed?

The latter would be quite a nightmare.  A bug report about an
error in package-1.1_pre6 isn't really helpful when everyone's _pre6 is
a completely different revision.

The former, as Marius said, requires knowledge of how to get a sane
revision id from every SCM we want to support to be built into
the package manager.

I wonder if instead of rev id, we could use a timestamp to fill in
_pre.  It's not ideal but it narrows the checkout down somewhat.
Also, we could use pkg_info to report revision numbers (for those SCM's
that have such a thing).  The combination of the two might be enough -
you'd have the revision you installed, when you installed it, and an
automatic incrementor for those ppl who like those kinds of things.

> * How are you planning to handle reinstalls? Should installing world
> always reinstall live things? Never? Or what?
>
> * How are live ebuilds selected by the package manager?

How are reinstalls handled for -9999 ebuilds now?  I wouldn't think
it would need to change.  You'd have to unmask the live ebuild, then it
would only be reinstalled if you used --emptytree or specifically asked
for it on the command line.  I'm not sure this preN+1 thing makes
sense.  If a user wants to automatically update a live ebuild every
week, etc, they need to learn how to use cron. :P

If a dev wants to force a reinstall because of ebuild or patch changes
or whatever, they should still be able to use -rX as usual.

> A lot of projects work like this:
> 
> * trunk/ is current development, and is ahead of any release.
> 
> * branches/0.26/ is forked from trunk/ when 0.26 is released, and is
> equal to or ahead of any 0.26 release.
> 
> How does your proposal handle this?

I'm guessing the dev would need to change 0.26.live to 0.26.1.live when
0.26 was released.  I already need to do this with my live ebuilds.  Of
course, with some projects you never know if the next version will be
0.26.1, 0.27, or 0.3, or 1.0...

As for an ebuild tracking trunk, I guess we're back to -9999.live. ;P


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

Re: [gentoo-dev] Re: A few questions to our nominees

[Luca Barbato]

Ryan Hill wrote:
> On Fri, 13 Jun 2008 13:35:52 +0200
> Marius Mauch <genone@gentoo.org> wrote:
> 
>> Ignoring possible semantic issues for the moment, I'd be against this
>> simply because it would require the PM to be aware of the current
>> revision of the repository and to transform it into a integer value
>> (trivial for SVN, not so trivial for CVS for example). Which in turn
>> either means that the PM has to internally support the SCMs or support
>> some new phase functions to extract the revision.
> 
> I'm confused.  If I have a gcc-4.4.0.live ebuild which checks out rev.
> 136737, after the merge do I have gcc-4.4.0_pre136737
> or gcc-4.4.0_pre1 (and gcc-4.4.0_pre2 next time I merge it, etc)
> installed?

it would be gcc-4.4.0_pre1 but you'll have the revision inside the 
ebuild as var so you can get it easily. (e.g. the description shows it)

> The former, as Marius said, requires knowledge of how to get a sane
> revision id from every SCM we want to support to be built into
> the package manager.

> 
> I wonder if instead of rev id, we could use a timestamp to fill in
> _pre.  It's not ideal but it narrows the checkout down somewhat.
> Also, we could use pkg_info to report revision numbers (for those SCM's
> that have such a thing).  The combination of the two might be enough -
> you'd have the revision you installed, when you installed it, and an
> automatic incrementor for those ppl who like those kinds of things.

I like better single digits but it's more or less the same as structure 
and code.

> If a dev wants to force a reinstall because of ebuild or patch changes
> or whatever, they should still be able to use -rX as usual.
> 
>> A lot of projects work like this:
>>
>> * trunk/ is current development, and is ahead of any release.
>>
>> * branches/0.26/ is forked from trunk/ when 0.26 is released, and is
>> equal to or ahead of any 0.26 release.
>>
>> How does your proposal handle this?
> 
> I'm guessing the dev would need to change 0.26.live to 0.26.1.live when
> 0.26 was released.  I already need to do this with my live ebuilds.  Of
> course, with some projects you never know if the next version will be
> 0.26.1, 0.27, or 0.3, or 1.0...

That's an upstream issue, all we should care is about getting a version 
value that makes sense for us, better if it does for them.

> As for an ebuild tracking trunk, I guess we're back to -9999.live. ;P

or just keep in mind that even trunk changes enough that you need to 
update the ebuild thus makes sense use a next supposed version.

lu

-- 

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

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: A few questions to our nominees

[Ciaran McCreesh]

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

On Sat, 14 Jun 2008 10:19:32 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> > I'm confused.  If I have a gcc-4.4.0.live ebuild which checks out
> > rev. 136737, after the merge do I have gcc-4.4.0_pre136737
> > or gcc-4.4.0_pre1 (and gcc-4.4.0_pre2 next time I merge it, etc)
> > installed?
> 
> it would be gcc-4.4.0_pre1 but you'll have the revision inside the 
> ebuild as var so you can get it easily. (e.g. the description shows
> it)

And when would gcc-4.4.0_pre2 become available?

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: A few questions to our nominees

[Luca Barbato]

Ciaran McCreesh wrote:
> On Sat, 14 Jun 2008 10:19:32 +0200
> Luca Barbato <lu_zero@gentoo.org> wrote:
>>> I'm confused.  If I have a gcc-4.4.0.live ebuild which checks out
>>> rev. 136737, after the merge do I have gcc-4.4.0_pre136737
>>> or gcc-4.4.0_pre1 (and gcc-4.4.0_pre2 next time I merge it, etc)
>>> installed?
>> it would be gcc-4.4.0_pre1 but you'll have the revision inside the 
>> ebuild as var so you can get it easily. (e.g. the description shows
>> it)
> 
> And when would gcc-4.4.0_pre2 become available?

It will be available once you trigger again the generation or if you put 
a normal ebuild with such name.

lu

-- 

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

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: A few questions to our nominees

[Ciaran McCreesh]

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

On Sat, 14 Jun 2008 11:53:51 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > On Sat, 14 Jun 2008 10:19:32 +0200
> > Luca Barbato <lu_zero@gentoo.org> wrote:
> >>> I'm confused.  If I have a gcc-4.4.0.live ebuild which checks out
> >>> rev. 136737, after the merge do I have gcc-4.4.0_pre136737
> >>> or gcc-4.4.0_pre1 (and gcc-4.4.0_pre2 next time I merge it, etc)
> >>> installed?
> >> it would be gcc-4.4.0_pre1 but you'll have the revision inside the 
> >> ebuild as var so you can get it easily. (e.g. the description shows
> >> it)
> > 
> > And when would gcc-4.4.0_pre2 become available?
> 
> It will be available once you trigger again the generation or if you
> put a normal ebuild with such name.

And what triggers said generation?

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: A few questions to our nominees

[Luca Barbato]

Ciaran McCreesh wrote:
> On Sat, 14 Jun 2008 11:53:51 +0200
> Luca Barbato <lu_zero@gentoo.org> wrote:
>> Ciaran McCreesh wrote:
>>> On Sat, 14 Jun 2008 10:19:32 +0200
>>> Luca Barbato <lu_zero@gentoo.org> wrote:
>>>>> I'm confused.  If I have a gcc-4.4.0.live ebuild which checks out
>>>>> rev. 136737, after the merge do I have gcc-4.4.0_pre136737
>>>>> or gcc-4.4.0_pre1 (and gcc-4.4.0_pre2 next time I merge it, etc)
>>>>> installed?
>>>> it would be gcc-4.4.0_pre1 but you'll have the revision inside the 
>>>> ebuild as var so you can get it easily. (e.g. the description shows
>>>> it)
>>> And when would gcc-4.4.0_pre2 become available?
>> It will be available once you trigger again the generation or if you
>> put a normal ebuild with such name.
> 
> And what triggers said generation?

I already replied in this thread, I guess the information is getting too 
spread (and will be a pain put it back to the glep) =/

dev-zero pointed out that he would like to trigger the generation on a 
timely basis, I wanted to trigger it on the sync event, others had other 
opinion, so the best would be have it as separate phase and trigger it 
from the maint application.

lu

-- 

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

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: A few questions to our nominees

[Ciaran McCreesh]

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

On Sat, 14 Jun 2008 12:04:45 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> >> It will be available once you trigger again the generation or if
> >> you put a normal ebuild with such name.
> > 
> > And what triggers said generation?
> 
> I already replied in this thread, I guess the information is getting
> too spread (and will be a pain put it back to the glep) =/
> 
> dev-zero pointed out that he would like to trigger the generation on
> a timely basis, I wanted to trigger it on the sync event, others had
> other opinion, so the best would be have it as separate phase and
> trigger it from the maint application.

And none of those are even close to a reasonable, implementable idea.

I'm getting the impression you really didn't think this through at all
before mailing your proposal. I suggest you go back to the start, work
out use cases, package manager interactions, how if at all ebuilds will
need to be adapted and several examples. There's a big difference
between a few vague ideas and the foundations for an implementable
proposal.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: A few questions to our nominees

[Luca Barbato]

Ciaran McCreesh wrote:
> On Sat, 14 Jun 2008 12:04:45 +0200
> Luca Barbato <lu_zero@gentoo.org> wrote:
>>>> It will be available once you trigger again the generation or if
>>>> you put a normal ebuild with such name.
>>> And what triggers said generation?
>> I already replied in this thread, I guess the information is getting
>> too spread (and will be a pain put it back to the glep) =/
>>
>> dev-zero pointed out that he would like to trigger the generation on
>> a timely basis, I wanted to trigger it on the sync event, others had
>> other opinion, so the best would be have it as separate phase and
>> trigger it from the maint application.
> 
> And none of those are even close to a reasonable, implementable idea.

They are implementable.

lu

-- 

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

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: A few questions to our nominees

[Ciaran McCreesh]

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

On Sat, 14 Jun 2008 12:45:31 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> > And none of those are even close to a reasonable, implementable
> > idea.
> 
> They are implementable.

They're really not. You haven't even begun to discuss:

* What generation looks like.
* How to select which ebuilds to trigger generation for.
* When specifically to trigger generation.
* Whether generation failure is possible, and what happens if it is.
* What to do when generated information is required but not available.
* The security implications of the previous point.
* What the impact upon upstream servers is, if any.
* How generation fits in with users doing system updates.
* How generation fits in with the highly differing frequencies of
upstream updates.
* How generation can be made to fit in without changes to the version
spec, whilst still 'making sense' and doing the right thing.

The answers to all of the above are highly non-trivial.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: A few questions to our nominees

[Luca Barbato]

Ciaran McCreesh wrote:
> * What generation looks like.
> * How to select which ebuilds to trigger generation for.
> * When specifically to trigger generation.
> * Whether generation failure is possible, and what happens if it is.
> * What to do when generated information is required but not available.
> * The security implications of the previous point.
> * What the impact upon upstream servers is, if any.
> * How generation fits in with users doing system updates.
> * How generation fits in with the highly differing frequencies of
> upstream updates.
> * How generation can be made to fit in without changes to the version
> spec, whilst still 'making sense' and doing the right thing.
> 
> The answers to all of the above are highly non-trivial.

Many of them applies as well to the alternative proposal, I wonder how 
you could say we, council, had to vote the other proposal given such 
(and other) issues were open.

lu

-- 

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

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: A few questions to our nominees

[Ciaran McCreesh]

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

On Sat, 14 Jun 2008 14:27:22 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> Many of them applies as well to the alternative proposal, I wonder
> how you could say we, council, had to vote the other proposal given
> such (and other) issues were open.

No they don't. The alternative proposal is deliberately simple enough
to avoid those issues, whilst leaving the possibility of a larger
solution that does have scm revision awareness open for the future.

Does this mean you don't have answers then?

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: A few questions to our nominees

[Luca Barbato]

Ciaran McCreesh wrote:
> On Sat, 14 Jun 2008 14:27:22 +0200
> Luca Barbato <lu_zero@gentoo.org> wrote:
>> Many of them applies as well to the alternative proposal, I wonder
>> how you could say we, council, had to vote the other proposal given
>> such (and other) issues were open.
> 
> No they don't.

False.

> Does this mean you don't have answers then?

 From start I asked for help and from start I said that my proposal is 
anything but complete. I have no delusion to have all the answers at 
hand anytime.

lu

-- 

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

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: A few questions to our nominees

[Ciaran McCreesh]

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

On Sat, 14 Jun 2008 15:15:45 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > On Sat, 14 Jun 2008 14:27:22 +0200
> > Luca Barbato <lu_zero@gentoo.org> wrote:
> >> Many of them applies as well to the alternative proposal, I wonder
> >> how you could say we, council, had to vote the other proposal given
> >> such (and other) issues were open.
> > 
> > No they don't.
> 
> False.

Which of the issues I listed needs to be addressed for the scm proposal?

> > Does this mean you don't have answers then?
> 
>  From start I asked for help and from start I said that my proposal
> is anything but complete. I have no delusion to have all the answers
> at hand anytime.

Ok, here's the best help I can give you: Your proposal can't work. You
can't get correct ordering reusing existing components. You can't get
sane behaviour using your template scheme without making it aware of
scm revisions. You can't make it scm revision aware without a hell
of a lot of work. And if you do want to make it scm revision aware, you
need changes to the version scheme anyway.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: A few questions to our nominees

[Luca Barbato]

Ciaran McCreesh wrote:
> Which of the issues I listed needs to be addressed for the scm proposal?

At least the upstream server load.

> Ok, here's the best help I can give you: Your proposal can't work. You
> can't get correct ordering reusing existing components. You can't get
> sane behaviour using your template scheme without making it aware of
> scm revisions. You can't make it scm revision aware without a hell
> of a lot of work. And if you do want to make it scm revision aware, you
> need changes to the version scheme anyway.

Other people seem to think it's feasible, I think my proposal nicer and 
giving some value for the effort of implementing it, -scm adds a some 
work to do with undefined features at best.

lu

-- 

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

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: A few questions to our nominees

[Ciaran McCreesh]

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

On Sat, 14 Jun 2008 15:29:00 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > Which of the issues I listed needs to be addressed for the scm
> > proposal?
> 
> At least the upstream server load.

-scm doesn't attempt to use upstream to obtain any information.
Upstream is only contacted when people install or reinstall packages,
the same as for -9999 versions currently.

> Other people seem to think it's feasible

Jumping to that conclusion from such a vague proposal suggests that not
much thought has gone into thinking that...

> I think my proposal nicer and giving some value for the effort of
> implementing it

And I think it's not even far enough to be called a proposal, and we
can't sensibly discuss any of it until it is.

> -scm adds a some work to do with undefined features at best.

-scm is trivial.

-- 
Ciaran McCreesh

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

[gentoo-dev] Re: A few questions to our nominees

[Ryan Hill]

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

On Sat, 14 Jun 2008 14:01:15 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Sat, 14 Jun 2008 14:27:22 +0200
> Luca Barbato <lu_zero@gentoo.org> wrote:
> > Many of them applies as well to the alternative proposal, I wonder
> > how you could say we, council, had to vote the other proposal given
> > such (and other) issues were open.
> 
> No they don't. The alternative proposal is deliberately simple enough
> to avoid those issues, whilst leaving the possibility of a larger
> solution that does have scm revision awareness open for the future.

Just curious, were you happy with the previous GLEP54 draft or were
there still issues that had to be addressed?  As far as I'm concerned
it's fine.  (though I would change the suffix to -live, just because i
hate the term "SCM" :P)


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

Re: [gentoo-dev] Re: A few questions to our nominees

[Ciaran McCreesh]

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

On Sat, 14 Jun 2008 08:45:08 -0600
Ryan Hill <dirtyepic@gentoo.org> wrote:
> Just curious, were you happy with the previous GLEP54 draft or were
> there still issues that had to be addressed?  As far as I'm concerned
> it's fine.  (though I would change the suffix to -live, just because i
> hate the term "SCM" :P)

I'm happy with GLEP 54 as being the first, easy half of getting proper
scm support. It correctly solves the ordering and identification issues.

The second, really difficult part is making the package manager aware
of upstream scm revisions. That can be done later by building upon
GLEP 54.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: A few questions to our nominees

[Joe Peterson]

Ryan Hill wrote:
> (...I would change the suffix to -live, just because i
> hate the term "SCM" :P)

++ on using "live" and not the "scm" acronym (no matter which idea is
selected), especially since there are various different acronyms for
config mgmt (scm, cm...), and scm's meaning is less obvious at first glance.

	-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: A few questions to our nominees

[Luca Barbato]

Ciaran McCreesh wrote:
> * What generation looks like.

Mostly implementation detail? Somebody seems to have ideas there and I 
like to heard ideas from others as well.

> * How to select which ebuilds to trigger generation for.

I'm fond of sets and I'd extend maint to be feeded to sets other than 
world and all.

> * When specifically to trigger generation.

User decision or triggered by sync depending on a FEATURE.

> * Whether generation failure is possible, and what happens if it is.

I could think easily that such thing could happen (no network is a 
possibility)

> * What to do when generated information is required but not available.

Consider the ebuild corrupted or do not generate it.

> * The security implications of the previous point.

None?

> * What the impact upon upstream servers is, if any.

Shared with glep 54

> * How generation fits in with users doing system updates.

Orthogonal

> * How generation fits in with the highly differing frequencies of
> upstream updates.

Being user driven isn't an issue at all.

> * How generation can be made to fit in without changes to the version
> spec, whilst still 'making sense' and doing the right thing.

Discussion going on in this thread, so far Coldwind did quite well to 
pointing actual cases present in portage already, discussion on them 
should help sorting out issues.

Using live sources is a security and stability concern by itself and by 
accepting that you are at the very end of the bleeding edge you 
acknowledge that you are experimenting.

lu

-- 

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

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: A few questions to our nominees

[Ciaran McCreesh]

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

On Sat, 14 Jun 2008 15:25:53 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > * What generation looks like.
> 
> Mostly implementation detail? Somebody seems to have ideas there and
> I like to heard ideas from others as well.

It's not a detail. It's extremely important, and we can't discuss this
sanely until we have detailed proposals for this.

> > * How to select which ebuilds to trigger generation for.
> 
> I'm fond of sets and I'd extend maint to be feeded to sets other than 
> world and all.

Again, details.

> > * When specifically to trigger generation.
> 
> User decision or triggered by sync depending on a FEATURE.

Again, details. This one *really* needs to be worked out, since it's
getting in the way of discussing other implications.

> > * The security implications of the previous point.
> 
> None?

Well, generated revision numbers may have to be stored somewhere.
Should a normal user be able to force a generation? If not, this means
having to generate templates at sync time for every scm package in the
tree, which in turn means scanning every ebuild in the tree.

> > * What the impact upon upstream servers is, if any.
> 
> Shared with glep 54

GLEP 54 doesn't use upstream scm revision information at all. Are you
definitely saying that your proposal will not be tied in to upstream
revisions in any way?

-- 
Ciaran McCreesh

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

[gentoo-dev] Re: A few questions to our nominees

[Ryan Hill]

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

On Sat, 14 Jun 2008 11:53:51 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:

> Ciaran McCreesh wrote:
> > On Sat, 14 Jun 2008 10:19:32 +0200
> > Luca Barbato <lu_zero@gentoo.org> wrote:
> >>> I'm confused.  If I have a gcc-4.4.0.live ebuild which checks out
> >>> rev. 136737, after the merge do I have gcc-4.4.0_pre136737
> >>> or gcc-4.4.0_pre1 (and gcc-4.4.0_pre2 next time I merge it, etc)
> >>> installed?
> >> it would be gcc-4.4.0_pre1 but you'll have the revision inside the 
> >> ebuild as var so you can get it easily. (e.g. the description shows
> >> it)
> > 
> > And when would gcc-4.4.0_pre2 become available?
> 
> It will be available once you trigger again the generation or if you
> put a normal ebuild with such name.

So every user will have a different _preN version which would vary
depending on how often they rebuild the package and that has absolutely
no correlation with the revision number of the upstream codebase.  I'm
sorry, but that's unacceptable. :/

If a user reports a bug in package-1.1_pre6, how do you determine what
revision he has installed?  How can you even tell it's an scm ebuild?
If I want to report a bug I find to upstream, how to I know what
revision I have?  Yes there are hacks like ESCM_LOGDIR, but they're
different for every SCM and you have to opt-in to use them.  Most
people don't even know about them.

I think the request to create some kind of auto-updating system for
live ebuilds is a red herring, and will make finding a reasonable
solution much much harder than it should be.  If people want to
auto-update their live ebuilds they can simply put them in a cron job.


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

Re: [gentoo-dev] Re: A few questions to our nominees

[Luca Barbato]

Ryan Hill wrote:
> So every user will have a different _preN version which would vary
> depending on how often they rebuild the package and that has absolutely
> no correlation with the revision number of the upstream codebase.  I'm
> sorry, but that's unacceptable. :/

You'd like to have the cflags and ldflags embedded in the name for the 
same reason?

> If a user reports a bug in package-1.1_pre6, how do you determine what
> revision he has installed?  How can you even tell it's an scm ebuild?

You can. The generated ebuild must have a reference to the checkout.

> If I want to report a bug I find to upstream, how to I know what
> revision I have?  Yes there are hacks like ESCM_LOGDIR, but they're
> different for every SCM and you have to opt-in to use them.  Most
> people don't even know about them.

The generated ebuild contains pretty much everything you need to fill a 
bugreport.

lu

-- 

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

-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: A few questions to our nominees

[Ryan Hill]

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

On Sat, 14 Jun 2008 17:55:27 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:

> Ryan Hill wrote:
> > So every user will have a different _preN version which would vary
> > depending on how often they rebuild the package and that has
> > absolutely no correlation with the revision number of the upstream
> > codebase.  I'm sorry, but that's unacceptable. :/
> 
> You'd like to have the cflags and ldflags embedded in the name for
> the same reason?

There's no need to set up a strawman.  I expect that everyone
installing a version of a package is building from the same sources.
Do you really not see a problem here?

Okay, taking a different approach, what does an auto-incrementing
suffix gain us?  The ability to auto-merge a live ebuild at regular
intervals?  That's something that can easily be achieved without
mucking about mangling CPVs, in any implementation we decide on.  What
is it about your particular idea that makes it worth the numerous
disadvantages that we've pointed out?

> > If a user reports a bug in package-1.1_pre6, how do you determine
> > what revision he has installed?  How can you even tell it's an scm
> > ebuild?
> 
> You can. The generated ebuild must have a reference to the checkout.

This is the first time you've mentioned this.  Where would you find
such information?  How would you know that the ebuild the user is using
is a generated ebuild, and not just a standard ebuild that happens to
end in _pre6?  How would that information get into the ebuild?  Would
it have to come from the various VCS eclasses?  What about those that
don't have a way of getting at the revision number (like say
cvs.eclass)?  Would it have to be placed there by the package manager?
If so, then we're back to having to implement support for every VCS
inside the PM.

> > If I want to report a bug I find to upstream, how to I know what
> > revision I have?  Yes there are hacks like ESCM_LOGDIR, but they're
> > different for every SCM and you have to opt-in to use them.  Most
> > people don't even know about them.
> 
> The generated ebuild contains pretty much everything you need to fill
> a bugreport.

Could you please provide an example of a generated ebuild so we can see
what kinds of info it contains?


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

Re: [gentoo-dev] Re: A few questions to our nominees

[Luca Barbato]

Ryan Hill wrote:
> On Sat, 14 Jun 2008 17:55:27 +0200
> Luca Barbato <lu_zero@gentoo.org> wrote:
> 
>> Ryan Hill wrote:
>>> So every user will have a different _preN version which would vary
>>> depending on how often they rebuild the package and that has
>>> absolutely no correlation with the revision number of the upstream
>>> codebase.  I'm sorry, but that's unacceptable. :/
>> You'd like to have the cflags and ldflags embedded in the name for
>> the same reason?
> 
> There's no need to set up a strawman.  I expect that everyone
> installing a version of a package is building from the same sources.
> Do you really not see a problem here?

Well the idea is to have the revision/reference behave like CFLAGS and 
src_uri such variables, sorry if I just said that backwards.

> Okay, taking a different approach, what does an auto-incrementing
> suffix gain us?  The ability to auto-merge a live ebuild at regular
> intervals?  That's something that can easily be achieved without
> mucking about mangling CPVs, in any implementation we decide on.  What
> is it about your particular idea that makes it worth the numerous
> disadvantages that we've pointed out?

I don't see disadvantages, all I wanted is a simple way to archive this:

# emaint -r ffmpeg

# emerge ffmpeg -p

[ebuild     U ] media-video/ffmpeg-0.4.9_pre1235 [0.4.9_pre1234] [1]

[1] from ffmpeg-0.4.9.live

# emerge ffmpeg

fails, configure changed

# vim /usr/portage/media-video/ffmpeg-0.4.9.live.ebuild *1*

fix it

# emerge ffmpeg -L

builds as should test suite ok, further tests ok, everything builds 
using it.

# egen ffmpeg 0.4.9_p${date} *2*

# scp /usr/portage/distfiles/ffmpeg-0.4.9_p${date}.tar.bz2 
dev.gento.org:place
# cp usr/portage/media-video/ffmpeg/ffmpeg-0.4.9_p${date}.ebuild 
/var/cvs/gentoo-x86/media-video/ffmpeg/

# cd /var/cvs/gentoo-x86/media-video/ffmpeg/

# cvs add ffmpeg-0.4.9_p${date}.ebuild

# echangelog "New revision" && repoman ci -m "New revision"

[1] or just ffmpeg-0.4.9.live if you like better.
[2] emaint -g instead of egen

I do not want end users using this stuff.

>>> If a user reports a bug in package-1.1_pre6, how do you determine
>>> what revision he has installed?  How can you even tell it's an scm
>>> ebuild?
>> You can. The generated ebuild must have a reference to the checkout.
> 
> This is the first time you've mentioned this.

really? btw s/generated/recorded in the vdb.

> Where would you find such information?

from the vcs since on unpack or before I have to have the sources and 
thus the revision.

> How would you know that the ebuild the user is using is a generated ebuild,
> and not just a standard ebuild that happens to end in _pre6?

Being the maintainer I should know what's in the tree. If somebody 
happens to use an overlay that shadows the main tree how you'd be able 
to tell the difference from foo-1.2.3 and foo-1.2.3?

> How would that information get into the ebuild?  Would
> it have to come from the various VCS eclasses?

Right.

> What about those that don't have a way of getting at the revision number (like say
> cvs.eclass)?

A timestamp should do, I cannot think anything better. You want to have 
in the recorded ebuild everything useful to replay the process.

> Would it have to be placed there by the package manager?

Yes.

> If so, then we're back to having to implement support for every VCS
> inside the PM.

Having support inside the template to have such information in a 
variable you can save (as CFLAGS and friends) doesn't require this =)

>>> If I want to report a bug I find to upstream, how to I know what
>>> revision I have?  Yes there are hacks like ESCM_LOGDIR, but they're
>>> different for every SCM and you have to opt-in to use them.  Most
>>> people don't even know about them.
>> The generated ebuild contains pretty much everything you need to fill
>> a bugreport.
> 
> Could you please provide an example of a generated ebuild so we can see
> what kinds of info it contains?

I phrased that badly.

we have some phases:

given we have a simple ebuild

Once we get a new template we can trigger a phase that makes the pm 
consider the existence of an ebuild alike the current -9999 ones: they 
pick the tip of the branch chosen from the repository defined.
But with the version generated as already said.

If such ebuild get chosen for merge it behaves pretty much like the 
current ones, but the PM stores additional informations in the vdb 
(using current subversion.eclass as example it records the equivalent of 
ESVN_REVISION). Such informations let you know how to reproduce the 
build and let you generate a static snapshot automatically.

A dirty and simple way to implement this stuff right now (abusing 
everything) is to:

have a script that scans the tree for .live templates and generates 
ebuild out of them and places them in an overlay

have those ebuild rewrite themselves in the vdb adding the information 
needed.

Making it less dirty requires adding a new phase and possibly some new 
functions as ciaranm suggested.

-- 

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

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: A few questions to our nominees

[Peter Volkov]

В Сбт, 14/06/2008 в 19:28 +0200, Luca Barbato пишет:
> I don't see disadvantages, all I wanted is a simple way to archive this:

> [# emaint -r ffmpeg ... # emerge ffmpeg -L ... egen ... skipped most of stuff]

Your example shows that .live ebuilds "fix" different issue. What you
are suggesting are not live ebuilds but automation for snapshot
creation. And I don't see why you need .live ebuilds for this. Just
create ffmpeg-0.4.9_pre1235.ebuild and then increment number in _pre
part, create snapshot and be done (btw, automation of snapshot creation
was already discussed as pkg_maint() or maint_...(); bug 185567).

-- 
Peter.

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: A few questions to our nominees

[Bernd Steinhauser]

Ryan Hill schrieb:
> On Sat, 14 Jun 2008 11:53:51 +0200
> Luca Barbato <lu_zero@gentoo.org> wrote:
> 
>> Ciaran McCreesh wrote:
>>> On Sat, 14 Jun 2008 10:19:32 +0200
>>> Luca Barbato <lu_zero@gentoo.org> wrote:
>>>>> I'm confused.  If I have a gcc-4.4.0.live ebuild which checks out
>>>>> rev. 136737, after the merge do I have gcc-4.4.0_pre136737
>>>>> or gcc-4.4.0_pre1 (and gcc-4.4.0_pre2 next time I merge it, etc)
>>>>> installed?
>>>> it would be gcc-4.4.0_pre1 but you'll have the revision inside the 
>>>> ebuild as var so you can get it easily. (e.g. the description shows
>>>> it)
>>> And when would gcc-4.4.0_pre2 become available?
>> It will be available once you trigger again the generation or if you
>> put a normal ebuild with such name.
> 
> So every user will have a different _preN version which would vary
> depending on how often they rebuild the package and that has absolutely
> no correlation with the revision number of the upstream codebase.  I'm
> sorry, but that's unacceptable. :/
> 
> If a user reports a bug in package-1.1_pre6, how do you determine what
> revision he has installed?  How can you even tell it's an scm ebuild?
> If I want to report a bug I find to upstream, how to I know what
> revision I have?  Yes there are hacks like ESCM_LOGDIR, but they're
> different for every SCM and you have to opt-in to use them.  Most
> people don't even know about them.
No, the idea behind ESCM_LOGDIR was different.
If you just want the revision of the current installed thing, you can 
grep through the environment.

ESCM_LOGDIR mainly aimed to provide a history of revisions you 
installed. So that you can then tell upstream "Hey, I have this revision 
installed and it doesn't work, but this revision worked.".
So it is definitely related, but not the same.
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: A few questions to our nominees

[Ryan Hill]

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

On Sat, 14 Jun 2008 18:34:21 +0200
Bernd Steinhauser <gentoo@bernd-steinhauser.de> wrote:

> Ryan Hill schrieb:
> No, the idea behind ESCM_LOGDIR was different.
> If you just want the revision of the current installed thing, you can 
> grep through the environment.
> 
> ESCM_LOGDIR mainly aimed to provide a history of revisions you 
> installed. So that you can then tell upstream "Hey, I have this
> revision installed and it doesn't work, but this revision worked.".
> So it is definitely related, but not the same.

Well, true.  But it does give you the latest version you installed. ;)
It was the only example I could think of (and one I use constantly).

gcc is nice enough that i can do `gcc -v` and get

gcc version 4.3.2-pre20080612 built 20080614 (Gentoo SVN ebuild) rev.
136782 ()

but not everything works like that.


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

Re: [gentoo-dev] Re: A few questions to our nominees

[Santiago M. Mola]

On Sat, Jun 14, 2008 at 10:19 AM, Luca Barbato <lu_zero@gentoo.org> wrote:
> Ryan Hill wrote:
>>
>> I'm guessing the dev would need to change 0.26.live to 0.26.1.live when
>> 0.26 was released.  I already need to do this with my live ebuilds.  Of
>> course, with some projects you never know if the next version will be
>> 0.26.1, 0.27, or 0.3, or 1.0...
>
> That's an upstream issue, all we should care is about getting a version
> value that makes sense for us, better if it does for them.
>

I think upstream use release branches correctly here, and it's the
most widespread use.

There's some real examples where ".live" = "_pre" has problems.

* media-video/mplayer: I'd expect 1.0.live to be higher than 1.0_rc2,
but it doesn't. I'd also expect 1.0.live to be higher than 1.0 when
it's released.

* media-video/ffmpeg: Pretty much the same that mplayer, but a bit worse.

* x11-wm/enlightenment: latest release is 0.16.8.13, current live
ebuild is 0.16.9999. If we use ".live" here we'd need either
0.16.9999.live (which is quite pointless) or 0.16.8.14.live which
would need to be updated after every minor release. 0.17.live is not a
possibility at all since 0.17 is a rewrite from scratch and an entire
different application.

* media-sound/amarok: live version is 1.4.9999. Next version is 2.0,
but that's a different branch so I'd expect 2.0.live to give me the
latest 2.0 version available, not 1.4's.

With the current proposal, .live ebuilds should be changed after every
minor release, unless we use the number of the next release. Next
release isn't always known, and it's doesn't always make sense. This
puts us in a worse situation than with GLEP 54, or even with the
current use of .9999 components.

-- 
Santiago M. Mola
Jabber ID: cooldwind@gmail.com
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: A few questions to our nominees

[Diego 'Flameeyes' Pettenò]

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

"Santiago M. Mola" <coldwind@gentoo.org> writes:

> * media-sound/amarok: live version is 1.4.9999. Next version is 2.0,
> but that's a different branch so I'd expect 2.0.live to give me the
> latest 2.0 version available, not 1.4's.

1.4.9999 has been switched from 9999 because of the 2.0/1.4 branches,
9999 would be 2.0 (if I ever care enough to add that, not before a beta
is released for sure, and not before I can use KDE 4.1 daily, which is
not something I expect to happen soonish).

Just FYI.

-- 
Diego "Flameeyes" Pettenò
http://blog.flameeyes.eu/

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

Re: [gentoo-dev] Re: A few questions to our nominees

[Luca Barbato]

Santiago M. Mola wrote:
> On Sat, Jun 14, 2008 at 10:19 AM, Luca Barbato <lu_zero@gentoo.org> wrote:
>> Ryan Hill wrote:
>>> I'm guessing the dev would need to change 0.26.live to 0.26.1.live when
>>> 0.26 was released.  I already need to do this with my live ebuilds.  Of
>>> course, with some projects you never know if the next version will be
>>> 0.26.1, 0.27, or 0.3, or 1.0...
>> That's an upstream issue, all we should care is about getting a version
>> value that makes sense for us, better if it does for them.
>>
> 
> I think upstream use release branches correctly here, and it's the
> most widespread use.
> 
> There's some real examples where ".live" = "_pre" has problems.
> 
> * media-video/mplayer: I'd expect 1.0.live to be higher than 1.0_rc2,
> but it doesn't. I'd also expect 1.0.live to be higher than 1.0 when
> it's released.

MPlayer has a psychological issue with 1.0 versioning, still 1.0.live 
correctly isn't higher than 1.0

> 
> * media-video/ffmpeg: Pretty much the same that mplayer, but a bit worse.

No, ffmpeg does "continuous release" every commit must not add 
regressions and the ABI/API is marked, a correct version for ffmpeg is 
given by taking the combination of the libraries major version.

Every major version update I'll have to update the live ebuild because 
of that and this is correct.

> 
> * x11-wm/enlightenment: latest release is 0.16.8.13, current live
> ebuild is 0.16.9999. If we use ".live" here we'd need either
> 0.16.9999.live (which is quite pointless) or 0.16.8.14.live which
> would need to be updated after every minor release. 0.17.live is not a
> possibility at all since 0.17 is a rewrite from scratch and an entire
> different application.

0.16.9.live sounds that bad?

> With the current proposal, .live ebuilds should be changed after every
> minor release, unless we use the number of the next release.

You do pick what is good for you.

> Next release isn't always known, and it's doesn't always make sense. This
> puts us in a worse situation than with GLEP 54, or even with the
> current use of .9999 components.

I don't see how. Keep in mind that -9999 ebuild should just stay in 
overlay and shouldn't be used by average users. The should help us 
developer tracking projects and get us to the point of having a snapshot 
for common usage.


lu

-- 

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

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: A few questions to our nominees

[Bernd Steinhauser]

Luca Barbato schrieb:
> Santiago M. Mola wrote:
>> On Sat, Jun 14, 2008 at 10:19 AM, Luca Barbato <lu_zero@gentoo.org> 
>> wrote:
>>> Ryan Hill wrote:
>>>> I'm guessing the dev would need to change 0.26.live to 0.26.1.live when
>>>> 0.26 was released.  I already need to do this with my live ebuilds.  Of
>>>> course, with some projects you never know if the next version will be
>>>> 0.26.1, 0.27, or 0.3, or 1.0...
>>> That's an upstream issue, all we should care is about getting a version
>>> value that makes sense for us, better if it does for them.
>>>
>>
>> I think upstream use release branches correctly here, and it's the
>> most widespread use.
>>
>> There's some real examples where ".live" = "_pre" has problems.
>>
>> * media-video/mplayer: I'd expect 1.0.live to be higher than 1.0_rc2,
>> but it doesn't. I'd also expect 1.0.live to be higher than 1.0 when
>> it's released.
> 
> MPlayer has a psychological issue with 1.0 versioning, still 1.0.live 
> correctly isn't higher than 1.0
No, it is not.

Take KDE for example, they have trunk currently, that will become KDE 
4.1.0. When that has been released, there will be a branch 4.1, which is 
ahead of 4.1.0 and will become 4.1.1, then 4.1.2 (when 4.1.1 has been 
released) etc.

In the -scm approach this means:
trunk = -scm
4.1 branch = -4.1-scm

With your approach, we would have to fix the version after every 4.1.x 
release. That sounds awful, tbh. So:
trunk = .live
4.1 branch = 4.1.1.live (before 4.1.1 has been released)
4.1 branch = 4.1.2.live (before 4.1.2 has been released)
4.1 branch = 4.1.3.live (before 4.1.3 has been released)
...
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: A few questions to our nominees

[Luca Barbato]

Bernd Steinhauser wrote:
>> MPlayer has a psychological issue with 1.0 versioning, still 1.0.live 
>> correctly isn't higher than 1.0
> No, it is not.

For mplayer it is correct. I'm MPlayer upstream as well. I do know.

> In the -scm approach this means:
> trunk = -scm
> 4.1 branch = -4.1-scm

so you'll be oblivious of changes needed inside the ebuild and you won't 
know what you merged last time you issued an emerge =foo-scm (that by 
itself it is a problem, since it is ambiguous)

> With your approach, we would have to fix the version after every 4.1.x 
> release. That sounds awful, tbh. So:

No that enforce people update the deps or at least gives one more reason 
to do. Keep in mind that -9999, -scm ebuild or .live templates aren't 
for public consumption.

> trunk = .live

nope it would resolve as foo_pre1 -> meaningless.

> 4.1 branch = 4.1.1.live (before 4.1.1 has been released)

correct, you can keep tracking 4.1.1, have interim snapshot pushed in 
portage to ~ if you are confident about them.

> 4.1 branch = 4.1.2.live (before 4.1.2 has been released)
> 4.1 branch = 4.1.3.live (before 4.1.3 has been released)

same reasoning.

lu

-- 

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

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: A few questions to our nominees

[Fernando J. Pereda]

On 14 Jun 2008, at 18:03, Luca Barbato wrote:
>> trunk = .live
>
> nope it would resolve as foo_pre1 -> meaningless.

So your proposal is unable to handle that case, right?

- ferdy

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: A few questions to our nominees

[Luca Barbato]

Fernando J. Pereda wrote:
>> nope it would resolve as foo_pre1 -> meaningless.
> 
> So your proposal is unable to handle that case, right?

You are forced to put a version, that's all.

lu

-- 

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

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: A few questions to our nominees

[Fernando J. Pereda]

On 14 Jun 2008, at 18:23, Luca Barbato wrote:

> Fernando J. Pereda wrote:
>>> nope it would resolve as foo_pre1 -> meaningless.
>> So your proposal is unable to handle that case, right?
>
> You are forced to put a version, that's all.

Which doesn't always make sense so we are back to 999999999 versions.  
I don't consider this an improvement over the current situation.

- ferdy

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: A few questions to our nominees

[Bernd Steinhauser]

Luca Barbato schrieb:
> Bernd Steinhauser wrote:
>> In the -scm approach this means:
>> trunk = -scm
>> 4.1 branch = -4.1-scm
> 
> so you'll be oblivious of changes needed inside the ebuild and you won't 
> know what you merged last time you issued an emerge =foo-scm (that by 
> itself it is a problem, since it is ambiguous)
Huh? What has to do with the ordering?
And finding out what I installed last time is trivial and not the point.

>> With your approach, we would have to fix the version after every 4.1.x 
>> release. That sounds awful, tbh. So:
> 
> No that enforce people update the deps or at least gives one more reason 
> to do. Keep in mind that -9999, -scm ebuild or .live templates aren't 
> for public consumption.
Except, that it is not that easy.
The point of time where you have to update your kde deps has nothing to 
do with that.
This is why we recommend to always reinstall everything from kde svn.
It is even more likely, that these problems occur after the "bump", that 
shouldn't have been one at all.

> 
>> trunk = .live
> 
> nope it would resolve as foo_pre1 -> meaningless.
> 
>> 4.1 branch = 4.1.1.live (before 4.1.1 has been released)
> 
> correct, you can keep tracking 4.1.1, have interim snapshot pushed in 
> portage to ~ if you are confident about them.
Of course I can track 4.1.1 with -scm, too, but that was absolutely not 
the point and is by far not what I wanted.
The point was to track the 4.1 branch and not tags inside.


I have got a feeling, that you didn't have to deal with live packages 
that much yet. (No offense.)
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: A few questions to our nominees

[Luca Barbato]

Bernd Steinhauser wrote:
>>> With your approach, we would have to fix the version after every 
>>> 4.1.x release. That sounds awful, tbh. So:
>>
>> No that enforce people update the deps or at least gives one more 
>> reason to do. Keep in mind that -9999, -scm ebuild or .live templates 
>> aren't for public consumption.
> Except, that it is not that easy.
> The point of time where you have to update your kde deps has nothing to 
> do with that.
> This is why we recommend to always reinstall everything from kde svn.
> It is even more likely, that these problems occur after the "bump", that 
> shouldn't have been one at all.

emerge -C @kde-svn

emerge @kde-svn

that should suffice.

> Of course I can track 4.1.1 with -scm, too, but that was absolutely not 
> the point and is by far not what I wanted.
> The point was to track the 4.1 branch and not tags inside.

If you want to track something you write a template for such thing, you 
just need to put a meaningful name, portage won't care if foo-0.live is 
really bar branch baz from repo dup.

Advanced testers should be able to pick the live template and help 
testing and should be able to smoothly update, I'm all for it.

> I have got a feeling, that you didn't have to deal with live packages 
> that much yet. (No offense.)

Beside e17 and ffmpeg you mean?

lu

-- 

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

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: A few questions to our nominees

[Fernando J. Pereda]

On 14 Jun 2008, at 19:36, Luca Barbato wrote:

> Bernd Steinhauser wrote:
>>>> With your approach, we would have to fix the version after every  
>>>> 4.1.x release. That sounds awful, tbh. So:
>>>
>>> No that enforce people update the deps or at least gives one more  
>>> reason to do. Keep in mind that -9999, -scm ebuild or .live  
>>> templates aren't for public consumption.
>> Except, that it is not that easy.
>> The point of time where you have to update your kde deps has  
>> nothing to do with that.
>> This is why we recommend to always reinstall everything from kde svn.
>> It is even more likely, that these problems occur after the "bump",  
>> that shouldn't have been one at all.
>
> emerge -C @kde-svn
>
> emerge @kde-svn
>
> that should suffice.

I don't see that working for something like, say, python or glibc.

- ferdy

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: A few questions to our nominees

[Luca Barbato]

Fernando J. Pereda wrote:
> 
> On 14 Jun 2008, at 19:36, Luca Barbato wrote:
> 
>> Bernd Steinhauser wrote:
>>>>> With your approach, we would have to fix the version after every 
>>>>> 4.1.x release. That sounds awful, tbh. So:
>>>>
>>>> No that enforce people update the deps or at least gives one more 
>>>> reason to do. Keep in mind that -9999, -scm ebuild or .live 
>>>> templates aren't for public consumption.
>>> Except, that it is not that easy.
>>> The point of time where you have to update your kde deps has nothing 
>>> to do with that.
>>> This is why we recommend to always reinstall everything from kde svn.
>>> It is even more likely, that these problems occur after the "bump", 
>>> that shouldn't have been one at all.
>>
>> emerge -C @kde-svn
>>
>> emerge @kde-svn
>>
>> that should suffice.
> 
> I don't see that working for something like, say, python or glibc.

do you really want to use live ebuild of THOSE?

(btw they are single packages, emerge =python-9999 works as should)

lu

-- 

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

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: A few questions to our nominees

[Fernando J. Pereda]

On 14 Jun 2008, at 20:02, Luca Barbato wrote:
> Fernando J. Pereda wrote:
>> On 14 Jun 2008, at 19:36, Luca Barbato wrote:
>>> Bernd Steinhauser wrote:
>>>>>> With your approach, we would have to fix the version after  
>>>>>> every 4.1.x release. That sounds awful, tbh. So:
>>>>>
>>>>> No that enforce people update the deps or at least gives one  
>>>>> more reason to do. Keep in mind that -9999, -scm ebuild or .live  
>>>>> templates aren't for public consumption.
>>>> Except, that it is not that easy.
>>>> The point of time where you have to update your kde deps has  
>>>> nothing to do with that.
>>>> This is why we recommend to always reinstall everything from kde  
>>>> svn.
>>>> It is even more likely, that these problems occur after the  
>>>> "bump", that shouldn't have been one at all.
>>>
>>> emerge -C @kde-svn
>>>
>>> emerge @kde-svn
>>>
>>> that should suffice.
>> I don't see that working for something like, say, python or glibc.
>
> do you really want to use live ebuild of THOSE?

Why not?

> (btw they are single packages, emerge =python-9999 works as should)

So what was your proposal all about?

- ferdy

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: A few questions to our nominees

[Luca Barbato]

Fernando J. Pereda wrote:
> 
> On 14 Jun 2008, at 20:02, Luca Barbato wrote:
>> Fernando J. Pereda wrote:
>>> On 14 Jun 2008, at 19:36, Luca Barbato wrote:
>>>> Bernd Steinhauser wrote:
>>>>>>> With your approach, we would have to fix the version after every 
>>>>>>> 4.1.x release. That sounds awful, tbh. So:
>>>>>>
>>>>>> No that enforce people update the deps or at least gives one more 
>>>>>> reason to do. Keep in mind that -9999, -scm ebuild or .live 
>>>>>> templates aren't for public consumption.
>>>>> Except, that it is not that easy.
>>>>> The point of time where you have to update your kde deps has 
>>>>> nothing to do with that.
>>>>> This is why we recommend to always reinstall everything from kde svn.
>>>>> It is even more likely, that these problems occur after the "bump", 
>>>>> that shouldn't have been one at all.
>>>>
>>>> emerge -C @kde-svn
>>>>
>>>> emerge @kde-svn
>>>>
>>>> that should suffice.
>>> I don't see that working for something like, say, python or glibc.
>>
>> do you really want to use live ebuild of THOSE?
> 
> Why not?

mainline glibc usually requires you to fix it or the rest of the world...

>> (btw they are single packages, emerge =python-9999 works as should)
> 
> So what was your proposal all about?

Doing something more.

lu

-- 

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

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: A few questions to our nominees

[Fernando J. Pereda]

On 14 Jun 2008, at 22:18, Luca Barbato wrote:

> Fernando J. Pereda wrote:
>> On 14 Jun 2008, at 20:02, Luca Barbato wrote:
>>> Fernando J. Pereda wrote:
>>>> On 14 Jun 2008, at 19:36, Luca Barbato wrote:
>>>>> Bernd Steinhauser wrote:
>>>>>>>> With your approach, we would have to fix the version after  
>>>>>>>> every 4.1.x release. That sounds awful, tbh. So:
>>>>>>>
>>>>>>> No that enforce people update the deps or at least gives one  
>>>>>>> more reason to do. Keep in mind that -9999, -scm ebuild  
>>>>>>> or .live templates aren't for public consumption.
>>>>>> Except, that it is not that easy.
>>>>>> The point of time where you have to update your kde deps has  
>>>>>> nothing to do with that.
>>>>>> This is why we recommend to always reinstall everything from  
>>>>>> kde svn.
>>>>>> It is even more likely, that these problems occur after the  
>>>>>> "bump", that shouldn't have been one at all.
>>>>>
>>>>> emerge -C @kde-svn
>>>>>
>>>>> emerge @kde-svn
>>>>>
>>>>> that should suffice.
>>>> I don't see that working for something like, say, python or glibc.
>>>
>>> do you really want to use live ebuild of THOSE?
>> Why not?
>
> mainline glibc usually requires you to fix it or the rest of the  
> world...

What?


>>> (btw they are single packages, emerge =python-9999 works as should)
>> So what was your proposal all about?
>
> Doing something more.

How is using 9999 versions 'doing something more'?

- ferdy

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: A few questions to our nominees

[Luca Barbato]

Fernando J. Pereda wrote:
> On 14 Jun 2008, at 22:18, Luca Barbato wrote: 
>> mainline glibc usually requires you to fix it or the rest of the world...
> 
> What?

I experienced that the hard way -_-

>>>> (btw they are single packages, emerge =python-9999 works as should)
>>> So what was your proposal all about?
>>
>> Doing something more.
> 
> How is using 9999 versions 'doing something more'?

Using live templates is something more ^^;

lu

-- 

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

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: A few questions to our nominees

[Piotr Jaroszyński]

> Using live templates is something more ^^;

For now it looks to me like it is only more work. Could you please
clarify what new functionality they provide?

-- 
Best Regards,
Piotr Jaroszyński

Re: [gentoo-dev] Re: A few questions to our nominees

[Patrick Lauer]

> > emerge -C @kde-svn
> >
> > emerge @kde-svn
> >
> > that should suffice.
>
> I don't see that working for something like, say, python or glibc.

No need, emerge @kde-svn will re-merge all packages in the set by default. So 
unmerging isn't needed and it just works.

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: A few questions to our nominees

[Bernd Steinhauser]

Luca Barbato schrieb:
> Bernd Steinhauser wrote:
>>>> With your approach, we would have to fix the version after every 
>>>> 4.1.x release. That sounds awful, tbh. So:
>>>
>>> No that enforce people update the deps or at least gives one more 
>>> reason to do. Keep in mind that -9999, -scm ebuild or .live templates 
>>> aren't for public consumption.
>> Except, that it is not that easy.
>> The point of time where you have to update your kde deps has nothing 
>> to do with that.
>> This is why we recommend to always reinstall everything from kde svn.
>> It is even more likely, that these problems occur after the "bump", 
>> that shouldn't have been one at all.
> 
> emerge -C @kde-svn
> 
> emerge @kde-svn
> 
> that should suffice.
Wow, impressive.

Actually, you can't be serious...

>> Of course I can track 4.1.1 with -scm, too, but that was absolutely 
>> not the point and is by far not what I wanted.
>> The point was to track the 4.1 branch and not tags inside.
> 
> If you want to track something you write a template for such thing, you 
> just need to put a meaningful name, portage won't care if foo-0.live is 
> really bar branch baz from repo dup.
> 
> Advanced testers should be able to pick the live template and help 
> testing and should be able to smoothly update, I'm all for it.
See, the problem here is, that, I have been using -scm as proposed in 
GLEP 54 for quite some time now and it works very well.
I just don't see any benefit from your proposal, on the contrary there 
are issues.
And that includes the ordering.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: A few questions to our nominees

[Luca Barbato]

Bernd Steinhauser wrote:
> Wow, impressive.
> 
> Actually, you can't be serious...

I am.
> GLEP 54 for quite some time now and it works very well.

adds nothing to -9999 and sets usage as is.
> I just don't see any benefit from your proposal, on the contrary there 
> are issues.

No.

> And that includes the ordering.

No.


-- 

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

-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: A few questions to our nominees

[Ryan Hill]

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

On Sat, 14 Jun 2008 22:16:36 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:

> Bernd Steinhauser wrote:
> > Wow, impressive.
> > 
> > Actually, you can't be serious...
> 
> I am.
> > GLEP 54 for quite some time now and it works very well.
> 
> adds nothing to -9999 and sets usage as is.
> > I just don't see any benefit from your proposal, on the contrary
> > there are issues.
> 
> No.

Yes.

> 
> > And that includes the ordering.
> 
> No.

Yes.

GLEP 54 is fine as is.  Not one person has expressed approval at your
current proprosal, and many people from many different viewpoints have
expressed disapproval.   Simplying saying "no" does not make these
criticisms go away.


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

Re: [gentoo-dev] Re: A few questions to our nominees

[Luca Barbato]

Ryan Hill wrote:
> On Sat, 14 Jun 2008 22:16:36 +0200
> Luca Barbato <lu_zero@gentoo.org> wrote:
> 
>> Bernd Steinhauser wrote:
>>> Wow, impressive.
>>>
>>> Actually, you can't be serious...
>> I am.
>>> GLEP 54 for quite some time now and it works very well.
>> adds nothing to -9999 and sets usage as is.
>>> I just don't see any benefit from your proposal, on the contrary
>>> there are issues.
>> No.
> 
> Yes.

No, I spent some emails already before this one shorter addressing this, 
so a plain "No" is the right answer to reiterating.
> 
>>> And that includes the ordering.
>> No.
> 
> Yes.

Question answered again far before, if you dislike the answer you could 
pick that part of the thread and comment there.

Reiterated question gets shorter replies.

About glep-54:

emerge code-scm

what should fetch?

(given that code is an editor and code-scm is a plugin adding scm 
support...)

lu

-- 

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

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: A few questions to our nominees

[Ciaran McCreesh]

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

On Tue, 17 Jun 2008 10:59:37 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> About glep-54:
> 
> emerge code-scm
> 
> what should fetch?
> 
> (given that code is an editor and code-scm is a plugin adding scm 
> support...)

code-scm. There is no way of distinguishing between a c/p and a c/p-v,
which is why you have to use the =. GLEP 54 does not change that.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] A few questions to our nominees

[Luca Barbato]

Marius Mauch wrote:
> Ignoring possible semantic issues for the moment,

Please point them so I could fix them properly ^^

> I'd be against this simply because it would require the PM to be aware
> of the current revision of the repository and to transform it into a
> integer value (trivial for SVN, not so trivial for CVS for example).

You should be able to have a generic framework that just uses what the 
ebuild needs to get the sources, standardizing the live eclasses will be 
enough.

> Which in turn either means that the PM has to internally support the SCMs
> or support some new phase functions to extract the revision.

After some discussions with dev-zero, I think we'll need a new phase, 
possibly trigged by maint, before I was thinking about adding it to sync.

> Plus it has similar (unstated) transition issues as GLEP-54, just avoids
> a new comparison algorithm and the CPV vs. atom issue.

Hmm, give me more informations about your concern.

lu

-- 

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

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] A few questions to our nominees

[Marius Mauch]

On Sat, 14 Jun 2008 10:38:18 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:

> Marius Mauch wrote:
> > Ignoring possible semantic issues for the moment,
> 
> Please point them so I could fix them properly ^^

For example all the ordering issues pointed out by others in this
thread. Also the whole 'template' approach is likely going to introduce
a number of issues. And as your proposal is lacking a lot of details
more problems will come up over time.

> > Which in turn either means that the PM has to internally support
> > the SCMs or support some new phase functions to extract the
> > revision.
> 
> After some discussions with dev-zero, I think we'll need a new phase, 
> possibly trigged by maint, before I was thinking about adding it to
> sync.

What exactly do you mean with 'maint'?

> > Plus it has similar (unstated) transition issues as GLEP-54, just
> > avoids a new comparison algorithm and the CPV vs. atom issue.
> 
> Hmm, give me more informations about your concern.

Simply how would you actually introduce this stuff without breaking
existing setups?

Marius
-- 
gentoo-dev@lists.gentoo.org mailing list