[gentoo-dev] RFD : .ebuild is only bash

[gentoo-dev] RFD : .ebuild is only bash

[Kent Fredric]

On 12 March 2012 22:37, Brian Harring <ferringb@gmail.com> wrote:
> Ebuilds *are* bash.  There isn't ever going to be a PMS labeled
> xml format that is known as ebuilds... that's just pragmatic reality
> since such a beast is clearly a seperate format (thus trying to call
> it an 'ebuild' is dumb, confusing, and counter productive).


I think this notion should be concluded before we continue debating as
to how best to implement EAPI declarations.

Is it really so fixed that ".ebuild" will only ever be bash ?

If thats the case, then G55 ( or something similar ) is practically
guaranteed as soon as we want something non-bash.




--
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

Re: [gentoo-dev] RFD : .ebuild is only bash

[Ciaran McCreesh]

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

On Tue, 13 Mar 2012 04:57:04 +1300
Kent Fredric <kentfredric@gmail.com> wrote:
> I think this notion should be concluded before we continue debating as
> to how best to implement EAPI declarations.
> 
> Is it really so fixed that ".ebuild" will only ever be bash ?

What version of bash are we talking about here? It's not the case that
ebuilds will always be bash 3, which is enough to make GLEP 55 the safe
option.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFD : .ebuild is only bash

[Rich Freeman]

On Mon, Mar 12, 2012 at 11:59 AM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Tue, 13 Mar 2012 04:57:04 +1300
> Kent Fredric <kentfredric@gmail.com> wrote:
>> I think this notion should be concluded before we continue debating as
>> to how best to implement EAPI declarations.
>>
>> Is it really so fixed that ".ebuild" will only ever be bash ?
>
> What version of bash are we talking about here? It's not the case that
> ebuilds will always be bash 3, which is enough to make GLEP 55 the safe
> option.

Well, we do always have the option of keeping the EAPI= syntax but
making it more strict per the proposals, and then grepping it out
rather than sourcing the ebuild.  That seems likely to always work
with bash.  Then if we ever switched to some other format we'd have to
reconsider whether we want to tweak this approach further or adopt
GLEP 55.

If you envision a future where big changes are inevitable over the
long term, then just going with GLEP 55 is probably the cleanest
solution.  If you envision a future where we are likely to never move
away from bash, or if we do it is so far off that we're content to let
our children deal with it, then other approaches may seem nicer.

I guess the question is whether we need to future-proof against a
future that may never come.  Then again, as we're seeing from systemd
a lot of stuff that "always" was done in bash doesn't necessarily have
to stay that way.

Rich

Re: [gentoo-dev] RFD : .ebuild is only bash

[Ulrich Mueller]

>>>>> On Mon, 12 Mar 2012, Rich Freeman wrote:

> Well, we do always have the option of keeping the EAPI= syntax but
> making it more strict per the proposals, and then grepping it out
> rather than sourcing the ebuild. That seems likely to always work
> with bash. Then if we ever switched to some other format we'd have
> to reconsider whether we want to tweak this approach further or
> adopt GLEP 55.

As long as we stay with some textual format for ebuilds, the "header
comment" approach will always work, if its syntax is general enough.
(For example, requiring # as comment introducer would be stupid.)

And I don't expect that we will move away from bash within the next
two or three years, so there won't be any upgrade problems for systems
with old package managers.

> If you envision a future where big changes are inevitable over the
> long term, then just going with GLEP 55 is probably the cleanest
> solution. If you envision a future where we are likely to never move
> away from bash, or if we do it is so far off that we're content to
> let our children deal with it, then other approaches may seem nicer.

> I guess the question is whether we need to future-proof against a
> future that may never come. Then again, as we're seeing from systemd
> a lot of stuff that "always" was done in bash doesn't necessarily
> have to stay that way.

See above, even if we should ever move away from bash, GLEP 55 is
still not needed.

Ulrich

Re: [gentoo-dev] RFD : .ebuild is only bash

[Ciaran McCreesh]

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

On Mon, 12 Mar 2012 18:05:46 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:
> See above, even if we should ever move away from bash, GLEP 55 is
> still not needed.

...but we might as well go with GLEP 55 anyway, since GLEP 55
definitely works, whereas other solutions might work so long as we
don't do something unexpected.

This whole thing is just an exercise in trying to find excuses not to
use GLEP 55.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFD : .ebuild is only bash

[Michael Orlitzky]

On 03/12/12 13:12, Ciaran McCreesh wrote:
> On Mon, 12 Mar 2012 18:05:46 +0100
> Ulrich Mueller <ulm@gentoo.org> wrote:
>> See above, even if we should ever move away from bash, GLEP 55 is
>> still not needed.
> 
> ...but we might as well go with GLEP 55 anyway, since GLEP 55
> definitely works, whereas other solutions might work so long as we
> don't do something unexpected.
> 
> This whole thing is just an exercise in trying to find excuses not to
> use GLEP 55.
> 

Not understanding any of the politics involved, what are the technical
arguments against it?

Re: [gentoo-dev] RFD : .ebuild is only bash

[Ciaran McCreesh]

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

On Mon, 12 Mar 2012 13:17:15 -0400
Michael Orlitzky <michael@orlitzky.com> wrote:
> > This whole thing is just an exercise in trying to find excuses not
> > to use GLEP 55.
> > 
> 
> Not understanding any of the politics involved, what are the technical
> arguments against it?

The person who wrote it is one of Satan's little minions. Also, change
is bad.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFD : .ebuild is only bash

[Zac Medico]

On 03/12/2012 10:17 AM, Michael Orlitzky wrote:
> On 03/12/12 13:12, Ciaran McCreesh wrote:
>> On Mon, 12 Mar 2012 18:05:46 +0100
>> Ulrich Mueller <ulm@gentoo.org> wrote:
>>> See above, even if we should ever move away from bash, GLEP 55 is
>>> still not needed.
>>
>> ...but we might as well go with GLEP 55 anyway, since GLEP 55
>> definitely works, whereas other solutions might work so long as we
>> don't do something unexpected.
>>
>> This whole thing is just an exercise in trying to find excuses not to
>> use GLEP 55.
>>
> 
> Not understanding any of the politics involved, what are the technical
> arguments against it?

I think the bulk of resistance has been due to its use of an infinite
series of extensions, like .ebuild-5, .ebuild-6 and so on. GLEP 55
itself has since been amended to include a "one time extension change"
option [1].

[1]
http://www.gentoo.org/proj/en/glep/glep-0055.html#eapi-in-the-filename-with-one-time-extension-change
-- 
Thanks,
Zac

Re: [gentoo-dev] RFD : .ebuild is only bash

[Zac Medico]

On 03/12/2012 10:12 AM, Ciaran McCreesh wrote:
> On Mon, 12 Mar 2012 18:05:46 +0100
> Ulrich Mueller <ulm@gentoo.org> wrote:
>> See above, even if we should ever move away from bash, GLEP 55 is
>> still not needed.
> 
> ...but we might as well go with GLEP 55 anyway, since GLEP 55
> definitely works, whereas other solutions might work so long as we
> don't do something unexpected.
> 
> This whole thing is just an exercise in trying to find excuses not to
> use GLEP 55.

If we do go with a variant of GLEP 55, I'd prefer a variant that uses a
constant extension (like .eb) and places the EAPI string just after the
version component of the name. For example:

   foo-1.0-r1-eapi5.ebuild
-- 
Thanks,
Zac

Re: [gentoo-dev] RFD : .ebuild is only bash

[Ulrich Mueller]

>>>>> On Mon, 12 Mar 2012, Zac Medico wrote:

> If we do go with a variant of GLEP 55, I'd prefer a variant that uses a
> constant extension (like .eb) and places the EAPI string just after the
> version component of the name. For example:

>    foo-1.0-r1-eapi5.ebuild

This is so ugly... I guess I'll retire the same day when such an
abomination gets accepted. ;-)

(Still better than the original variant of GLEP 55 though.)

Ulrich

Re: [gentoo-dev] RFD : .ebuild is only bash

[Ciaran McCreesh]

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

On Mon, 12 Mar 2012 19:00:32 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:
> >>>>> On Mon, 12 Mar 2012, Zac Medico wrote:
> > If we do go with a variant of GLEP 55, I'd prefer a variant that
> > uses a constant extension (like .eb) and places the EAPI string
> > just after the version component of the name. For example:
> 
> >    foo-1.0-r1-eapi5.ebuild
> 
> This is so ugly... I guess I'll retire the same day when such an
> abomination gets accepted. ;-)
> 
> (Still better than the original variant of GLEP 55 though.)

I'm sorry, we're down to "it's ugly and someone already said no and I'll
throw my toys out of the pram if I don't get my way" as the arguments
against GLEP 55 now?

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFD : .ebuild is only bash

[Ulrich Mueller]

>>>>> On Mon, 12 Mar 2012, Ciaran McCreesh wrote:

> On Mon, 12 Mar 2012 19:00:32 +0100
> Ulrich Mueller <ulm@gentoo.org> wrote:
>> >>>>> On Mon, 12 Mar 2012, Zac Medico wrote:
>> > If we do go with a variant of GLEP 55, I'd prefer a variant that
>> > uses a constant extension (like .eb) and places the EAPI string
>> > just after the version component of the name. For example:
>> 
>> >    foo-1.0-r1-eapi5.ebuild
>> 
>> This is so ugly... I guess I'll retire the same day when such an
>> abomination gets accepted. ;-)

> I'm sorry, we're down to "it's ugly and someone already said no and
> I'll throw my toys out of the pram if I don't get my way" as the
> arguments against GLEP 55 now?

Note the smiley in my posting. And yes, it _is_ ugly.

>>>>> On Mon, 12 Mar 2012, Ciaran McCreesh wrote:

> The person who wrote it is one of Satan's little minions. Also,
> change is bad.

And you think that this is better?

Ulrich

Re: [gentoo-dev] RFD : .ebuild is only bash

[Ciaran McCreesh]

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

On Mon, 12 Mar 2012 19:17:31 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:
> > The person who wrote it is one of Satan's little minions. Also,
> > change is bad.
> 
> And you think that this is better?

Those *are* the arguments against GLEP 55 that we've had so far. You're
adding in "someone already said no" (and the people who said that were
discussing nonsense like using xattrs in its place, which should
immediately invalidate anything they said on the matter) and "it looks
ugly, but not just because I don't like the people who proposed it,
honest" to that. The only reason this discussion is going on is because
some people still think it's in their advantage politically to say no to
anything seen as coming from "the wrong people".

GLEP 55 is simple, it solves all the problems we have (including the
version issue, which everyone is conveniently ignoring), it doesn't
require us to guess what's going to happen next and it can be
implemented immediately. That's a rather big deal.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFD : .ebuild is only bash

[Ulrich Mueller]

>>>>> On Mon, 12 Mar 2012, Ciaran McCreesh wrote:
> GLEP 55 is simple, it solves all the problems we have (including the
> version issue, which everyone is conveniently ignoring), it doesn't
> require us to guess what's going to happen next and it can be
> implemented immediately. That's a rather big deal.

The "header comment" solution solves all these issues too, without
embedding unrelated information in the filename [1]. It can be
implemented immediately, too.

The argument that was always used against such solutions was that
it would "hurt performance". However, when the council asked for
benchmarks that would prove that point, nobody could provide them.

Ulrich

[1] <http://en.wikipedia.org/wiki/Filename> "The filename is metadata
about a file; a string used to uniquely identify a file stored on the
file system."

Re: [gentoo-dev] RFD : .ebuild is only bash

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 12/03/12 02:50 PM, Ulrich Mueller wrote:
>>>>>> On Mon, 12 Mar 2012, Ciaran McCreesh wrote:
>> GLEP 55 is simple, it solves all the problems we have (including
>> the version issue, which everyone is conveniently ignoring), it
>> doesn't require us to guess what's going to happen next and it
>> can be implemented immediately. That's a rather big deal.
> 
> The "header comment" solution solves all these issues too, without 
> embedding unrelated information in the filename [1]. It can be 
> implemented immediately, too.
> 
> The argument that was always used against such solutions was that 
> it would "hurt performance". However, when the council asked for 
> benchmarks that would prove that point, nobody could provide them.
> 
> Ulrich


Regarding the filename issue, and the potential in the future for
ebuilds that get parsed with other parsers:

Is there any particular reason why we would want multiple ebuilds for
a package to exist for the same version, but supporting different
EAPIs (ad therefore different parsers)?

If the answer to this is no, that there should always be only one
ebuild per package version, then chances are good that we should keep
the eapi (or other identifier) out of the file name.  However, if the
answer is yes, then the filename method is probably the cleanest way
to do this.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk9eRzkACgkQAJxUfCtlWe18WwD5AeXETH+J4X8d8P7TX76FPGPS
0vS2rrRZktpLp70TkcQA/0Cl2/OdSlfwi0CqC8IBJffsY3epXkqxhzPL8bwsNAoj
=Q5aK
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFD : .ebuild is only bash

[Ciaran McCreesh]

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

On Mon, 12 Mar 2012 14:58:01 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:
> If the answer to this is no, that there should always be only one
> ebuild per package version

That's already not the way things work, since different version
strings can be equal versions (and it's illegal to do this), so it's
not relevant to the discussion.

- -- 
Ciaran McCreesh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iEYEARECAAYFAk9eSAwACgkQ96zL6DUtXhGpEwCfWS9u6S4oqNebnRrofwqWKFAy
tGMAoNX/2T7dyBqW+sSVO+O5nSMp5NKm
=Y5Tt
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFD : .ebuild is only bash

[Ulrich Mueller]

>>>>> On Mon, 12 Mar 2012, Ciaran McCreesh wrote:

> On Mon, 12 Mar 2012 14:58:01 -0400
> Ian Stakenvicius <axs@gentoo.org> wrote:
>> If the answer to this is no, that there should always be only one
>> ebuild per package version

Right.

> That's already not the way things work, since different version
> strings can be equal versions (and it's illegal to do this),
> so it's not relevant to the discussion.

This is a design flaw in our versioning system, and it can only occur
in some corner cases where version components have leading zeros. It
would be much better if any two different version strings had a unique
order relation (as for example it is the case with strverscmp(3)).

But that's not an excuse for adding another such flaw to our naming
scheme.

Ulrich

Re: [gentoo-dev] RFD : .ebuild is only bash

[Ciaran McCreesh]

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

On Mon, 12 Mar 2012 20:49:22 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:
> > That's already not the way things work, since different version
> > strings can be equal versions (and it's illegal to do this),
> > so it's not relevant to the discussion.
> 
> This is a design flaw in our versioning system, and it can only occur
> in some corner cases where version components have leading zeros.

You know, if we had GLEP 55, we could fix that. Although it's debatable
whether it's a flaw, since we're trying to match upstream version
formats where reasonably possible.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFD : .ebuild is only bash

[James Broadhead]

On 12 March 2012 20:10, Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> On Mon, 12 Mar 2012 20:49:22 +0100
> Ulrich Mueller <ulm@gentoo.org> wrote:
>> > That's already not the way things work, since different version
>> > strings can be equal versions (and it's illegal to do this),
>> > so it's not relevant to the discussion.
>>
>> This is a design flaw in our versioning system, and it can only occur
>> in some corner cases where version components have leading zeros.
>
> You know, if we had GLEP 55, we could fix that. Although it's debatable
> whether it's a flaw, since we're trying to match upstream version
> formats where reasonably possible.
>
> --
> Ciaran McCreesh

I'm sure that it's been considered already, but what are the arguments
against embedding the EAPI on a per-package (default) or per-version
basis in metadata.xml. It IS metadata after all.

Something like:
<eapi>6</eapi>  <!-- Default EAPI unless a versioned tag exists. -->

<eapi version="=1.2.*">4</eapi>
<eapi version="<1.2">3</eapi>

Where the version attribute should presumably have the same syntax as
versions in package.* already.

Re: [gentoo-dev] RFD : .ebuild is only bash

[Ulrich Mueller]

>>>>> On Mon, 12 Mar 2012, James Broadhead wrote:

> I'm sure that it's been considered already, but what are the arguments
> against embedding the EAPI on a per-package (default) or per-version
> basis in metadata.xml. It IS metadata after all.

You can find a recent discussion in bug 402167, comment #4 and
following. <https://bugs.gentoo.org/show_bug.cgi?id=402167#c4>

Ulrich

Re: [gentoo-dev] RFD : .ebuild is only bash

[Kent Fredric]

On 13 March 2012 10:14, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>>>> On Mon, 12 Mar 2012, James Broadhead wrote:
>
>> I'm sure that it's been considered already, but what are the arguments
>> against embedding the EAPI on a per-package (default) or per-version
>> basis in metadata.xml. It IS metadata after all.
>
> You can find a recent discussion in bug 402167, comment #4 and
> following. <https://bugs.gentoo.org/show_bug.cgi?id=402167#c4>

I note that there is a link to the council minutes, with the reason
for voting "no" against GLEP55 being "it has issues that are
unsolved", but I don't see any reference to said issues.

Is the actual IRC transcript available? Because I'd hate for this
decision to have been made on the assumption of issues which didn't
really exist.



-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

Re: [gentoo-dev] RFD : .ebuild is only bash

[Alec Warner]

On Mon, Mar 12, 2012 at 2:28 PM, Kent Fredric <kentfredric@gmail.com> wrote:
> On 13 March 2012 10:14, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>>>>> On Mon, 12 Mar 2012, James Broadhead wrote:
>>
>>> I'm sure that it's been considered already, but what are the arguments
>>> against embedding the EAPI on a per-package (default) or per-version
>>> basis in metadata.xml. It IS metadata after all.
>>
>> You can find a recent discussion in bug 402167, comment #4 and
>> following. <https://bugs.gentoo.org/show_bug.cgi?id=402167#c4>
>
> I note that there is a link to the council minutes, with the reason
> for voting "no" against GLEP55 being "it has issues that are
> unsolved", but I don't see any reference to said issues.
>
> Is the actual IRC transcript available? Because I'd hate for this
> decision to have been made on the assumption of issues which didn't
> really exist.

The previous council's decision does not prevent this same glep from
going to the council again (decisions are not forever.)
Some folks seem to think that taking glep55 back to the council is not
allowed somehow (or is perhaps futile, but that is a different issue
;p) Having the full notes would be helpful in determining why it was
turned down back then; I'm sure a copy of the notes exist.

-A

>
>
>
> --
> Kent
>
> perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
> 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"
>

Re: [gentoo-dev] RFD : .ebuild is only bash

[Mike Gilbert]

On Mon, Mar 12, 2012 at 5:49 PM, Alec Warner <antarus@gentoo.org> wrote:
> On Mon, Mar 12, 2012 at 2:28 PM, Kent Fredric <kentfredric@gmail.com> wrote:
>> On 13 March 2012 10:14, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>>>>>> On Mon, 12 Mar 2012, James Broadhead wrote:
>>>
>>>> I'm sure that it's been considered already, but what are the arguments
>>>> against embedding the EAPI on a per-package (default) or per-version
>>>> basis in metadata.xml. It IS metadata after all.
>>>
>>> You can find a recent discussion in bug 402167, comment #4 and
>>> following. <https://bugs.gentoo.org/show_bug.cgi?id=402167#c4>
>>
>> I note that there is a link to the council minutes, with the reason
>> for voting "no" against GLEP55 being "it has issues that are
>> unsolved", but I don't see any reference to said issues.
>>
>> Is the actual IRC transcript available? Because I'd hate for this
>> decision to have been made on the assumption of issues which didn't
>> really exist.
>
> The previous council's decision does not prevent this same glep from
> going to the council again (decisions are not forever.)
> Some folks seem to think that taking glep55 back to the council is not
> allowed somehow (or is perhaps futile, but that is a different issue
> ;p) Having the full notes would be helpful in determining why it was
> turned down back then; I'm sure a copy of the notes exist.

http://www.gentoo.org/proj/en/council/
http://www.gentoo.org/proj/en/council/meeting-logs/20100823.txt

Re: [gentoo-dev] RFD : .ebuild is only bash

[Kent Fredric]

On 13 March 2012 11:02, Mike Gilbert <floppym@gentoo.org> wrote:
>> The previous council's decision does not prevent this same glep from
>> going to the council again (decisions are not forever.)
>> Some folks seem to think that taking glep55 back to the council is not
>> allowed somehow (or is perhaps futile, but that is a different issue
>> ;p) Having the full notes would be helpful in determining why it was
>> turned down back then; I'm sure a copy of the notes exist.
>
> http://www.gentoo.org/proj/en/council/
> http://www.gentoo.org/proj/en/council/meeting-logs/20100823.txt
>

Well that was insightful. As suspected,, there was a lot of people
saying "Yeaahh, I don't like it", and concluding there were problems
with it, but the actual technical issues still haven't been presented
to us.

While they're still batting for the alternative solutions, which there
are known potential issues with.

Or did I read it selectively?

Can somebody present a real ( or even theoretical ) problem that could
arise from having the EAPI in the filename that isn't some abstract
hand-waving?

Not trying to be a troll here, but really, I still haven't seen any.


-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

Re: [gentoo-dev] RFD : .ebuild is only bash

[Alec Warner]

On Mon, Mar 12, 2012 at 3:37 PM, Kent Fredric <kentfredric@gmail.com> wrote:
> On 13 March 2012 11:02, Mike Gilbert <floppym@gentoo.org> wrote:
>>> The previous council's decision does not prevent this same glep from
>>> going to the council again (decisions are not forever.)
>>> Some folks seem to think that taking glep55 back to the council is not
>>> allowed somehow (or is perhaps futile, but that is a different issue
>>> ;p) Having the full notes would be helpful in determining why it was
>>> turned down back then; I'm sure a copy of the notes exist.
>>
>> http://www.gentoo.org/proj/en/council/
>> http://www.gentoo.org/proj/en/council/meeting-logs/20100823.txt
>>
>
> Well that was insightful. As suspected,, there was a lot of people
> saying "Yeaahh, I don't like it", and concluding there were problems
> with it, but the actual technical issues still haven't been presented
> to us.
>
> While they're still batting for the alternative solutions, which there
> are known potential issues with.
>
> Or did I read it selectively?
>
> Can somebody present a real ( or even theoretical ) problem that could
> arise from having the EAPI in the filename that isn't some abstract
> hand-waving?
>
> Not trying to be a troll here, but really, I still haven't seen any.

In general there was the 'I don't like it crowd (I was one of these, I
care less these days ;p)'
There was the 'it is Ciaran crowd.' This concept is difficult to
describe without a fair bit of context in how the community was being
run at the time.

None of the above reasons are what I would term 'technical merits.'
However now (as then) not all decisions are made on their technical
merits. We have adopted (and continue to adopt) solutions that are
imperfect, technically silly, or otherwise lots of work because they
meet some goal we are trying to accomplish. I don't think Gentoo is
alone in this aspect of management.

The inherent problem of course is that these merits are not provable,
so one cannot 'win' an argument on 'aesthetically pleasing filenames';
thus we are doomed to discuss glep55 until someone makes a decision in
favor or the proponents of the GLEP stop trying to push it (which is
what happened last time.)

-A

>
>
> --
> Kent
>
> perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
> 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"
>

[gentoo-dev] Re: RFD : .ebuild is only bash

[Duncan]

Alec Warner posted on Mon, 12 Mar 2012 15:53:58 -0700 as excerpted:

> On Mon, Mar 12, 2012 at 3:37 PM, Kent Fredric <kentfredric@gmail.com>
> wrote:
>> On 13 March 2012 11:02, Mike Gilbert <floppym@gentoo.org> wrote:
>>>> The previous council's decision does not prevent this same glep from
>>>> going to the council again (decisions are not forever.) [...]
>>>> Having the full notes would be helpful in determining why
>>>> it was turned down back then; I'm sure a copy of the notes exist.
>>>
>>> http://www.gentoo.org/proj/en/council/
>>> http://www.gentoo.org/proj/en/council/meeting-logs/20100823.txt
>>>
>>>
>> Well that was insightful. As suspected,, there was a lot of people
>> saying "Yeaahh, I don't like it", and concluding there were problems
>> with it, but the actual technical issues still haven't been presented
>> to us.

>> Can somebody present a real ( or even theoretical ) problem that could
>> arise from having the EAPI in the filename that isn't some abstract
>> hand-waving?

> In general there was the 'I don't like it crowd (I was one of these, I
> care less these days ;p)'
> There was the 'it is Ciaran crowd.' This concept is difficult to
> describe without a fair bit of context in how the community was being
> run at the time.

Sometimes I wonder at how much more pleasant the dev-list in particular 
is these days.  It's as if people grew up and learned how to have a 
reasonable discussion.  Meanwhile, I doubt anyone who survived those days 
wants to relive them, for sure!  So let's just agree not to kick that 
sleeping dog any more than we already have, lest he wake up!  The posts 
are after all archived for those newbies who wish to see for themselves 
what the veterans of the era would rather leave well enough alone.

> None of the above reasons are what I would term 'technical merits.'
> However now (as then) not all decisions are made on their technical
> merits. We have adopted (and continue to adopt) solutions that are
> imperfect, technically silly, or otherwise lots of work because they
> meet some goal we are trying to accomplish. I don't think Gentoo is
> alone in this aspect of management.

IMO the real reason for the g55 "no" back then, was that whatever the 
technical merits of the various solutions were, the discussion was simply 
too politically and interpersonally poisoned to handle in any reasonable 
way.  Gentoo lost some good folks around that time, and if the council 
had moved forward with ANY of the more forward looking proposals, 
including g55 but not limited to it, it would have very likely triggered 
a split of gentoo into at least two, likely three or four different 
factions, and gentoo as we know it would have gone the way that the zynot 
fork went...  Honestly, as bad as things were at the time and knowing 
that there ARE unstable folks like Hans Reiser around in the FLOSS 
community, I wouldn't have been /that/ surprised if someone really DID 
take it too far.  Yes, things were THAT bad!

Tho it's worth noting that the 2010 date of the log above was, I think, 
after the worst of it was over, but it was still too poisoned to deal 
with in any reasonably sane way.

Luckily, the council had the wisdom to more or less punt, voting down g55 
AND the other discussed solutions, basically sticking with what we had, 
with minor tweaks, until things calmed down.  It is my opinion that they 
really did very possibly prevented the rather bad end of gentoo by doing 
so.  But they did leave the door open, calling for further study of the 
issues.

When I saw this thread start, I wondered if enough time had passed...


The most encouraging thing about this current discussion for me as a list 
veteran of that era, is that despite all the posts so far, the debate has 
remained reasonably civil.  People are debating hard for their 
viewpoints, but nobody's crossing the line and making it personal as was 
the unfortunate norm back then, and people approaching the line are 
quickly nudged back away from it.

I honestly don't know if it's something that can be reasonably dealt 
with, yet.  I honestly don't know how pressing is the need to deal with 
it /now/ vs perhaps punting it a couple more years.

Either way, the simple fact that we're discussing it as sane humans 
instead of as a pack of wild dogs, viciously snarling and snapping at 
each other, is progress.

For the record, I agree with someone else, sorry I don't remember who, 
that said it seems that a lot of folks seem to want glep55 now, just not 
by that name.  Ultimately, I believe at least the one-shot variant, 
possibly with additional later shots but with each one well debated on 
its own merits to be SURE about it before moving forward (IOW, not an 
open-ended forever increasing series), with intermediate updates keeping 
the same filename structure in between, is about the best choice 
available.

But whether now's the appropriate time for that one-shot, and its 
details, I don't know.  At least our discussion is on sane terms, these 
days, something I don't believe could be honestly stated, before, and for 
that reason, I 100% agree with the council's rejection of it back then.



Meanwhile, for issues such as this, where we'll be living with the 
decision for some time to come, and especially where it has been going on 
for years, so another year isn't going to be life or death, I have an 
idea.

What about, for such issues, requiring, in effect, that two successive 
councils approve it, with possibly a 5/7 or even 6/7 override.  If the 
majority is that strong, it's unlikely that a new council would see it 
differently anyway.  If not, conditionally approve a decision, with the 
condition that the next year's council must also approve it.

Between the two approvals, any remaining implementation details can be 
worked out, and for decisions such as one affecting future EAPIs like 
this one does, implementation and testing can go into the PMs and if 
desired/necessary, the alternate tree prepared, but it can't roll-out 
"live" on the main gentoo tree (and any implementing overlays do so at a 
known and calculated risk of having to roll-back) until the second 
council approves the change as well.  And the first council's approval 
must be, say, a minimum of three months before council turnover.  No 
hasty post-election lame-duck sessions ramming stuff thru so the new 
council can in just weeks finalize things, tho of course the supermajority 
override still could, when really seen to be necessary by /that/ many 
council members.

That way, devs get to vote for a new council in the middle, and if they 
really dislike an action, they can simply vote in an opposing council.

Obviously, this only works for multi-year projects with multi-year 
implications, not so well for, say, appeals to council of a forced 
retirement or the like, but it seems to me that such a mechanism would 
guard quite well against one council voting something thru with a slim 
majority that's reverted the next year, for things with the long-term 
implications something like this obviously has.

Based on my reading of the logs, that's actually been a council concern a 
time or two, for at least a couple members.  Formally having the two-
successive-councils option for the biggest and longest term issues would 
remove that concern and allow the initial council to vote on the merits 
as they saw them, and a second council will have then certainly taken 
positions (even if it's an official "no position" position) on the issue, 
either by being reelected after the first vote or by statement, so can 
vote in confidence knowing that the larger gentoo developer pool backs 
them in their vote.

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

Re: [gentoo-dev] RFD : .ebuild is only bash

[James Broadhead]

On 12 March 2012 22:37, Kent Fredric <kentfredric@gmail.com> wrote:
>
> Can somebody present a real ( or even theoretical ) problem that could
> arise from having the EAPI in the filename that isn't some abstract
> hand-waving?
>
> Not trying to be a troll here, but really, I still haven't seen any.

This isn't a real-world problem, but we're arguably over-loading too
much information into the filename already;
- package name
- package version
- ebuild revision
- (EAPI?)

Re: [gentoo-dev] RFD : .ebuild is only bash

[Ulrich Mueller]

>>>>> On Mon, 12 Mar 2012, Alec Warner wrote:

> The previous council's decision does not prevent this same glep from
> going to the council again (decisions are not forever.)
> Some folks seem to think that taking glep55 back to the council is
> not allowed somehow (or is perhaps futile, but that is a different
> issue ;p) Having the full notes would be helpful in determining why
> it was turned down back then; I'm sure a copy of the notes exist.

Of course, decisions can be reconsidered. However, GLEP 55 was first
posted in 2007. We've had five councils since then, and none of these
councils has accepted it.

Also, this is one of the most controversial GLEPs that we ever had.
Even if it solves the technical problem for the package manager, I
believe that embedding such metadata information in the filename is
misguided.

Then the argument that GLEP 55 would be the only solution which
doesn't require a waiting period. Instead, we've been discussing it
since more than four years now (so it looks like we were not in a
hurry, and the urgent matters from 2007 haven't been so urgent, after
all). If some of the other less controversial solutions had been
implemented in 2008 or 2009, this wouldn't be an issue today.

Ulrich

Re: [gentoo-dev] RFD : .ebuild is only bash

[James Broadhead]

On 12 March 2012 21:14, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>>>> On Mon, 12 Mar 2012, James Broadhead wrote:
>
>> I'm sure that it's been considered already, but what are the arguments
>> against embedding the EAPI on a per-package (default) or per-version
>> basis in metadata.xml. It IS metadata after all.
>
> You can find a recent discussion in bug 402167, comment #4 and
> following. <https://bugs.gentoo.org/show_bug.cgi?id=402167#c4>
>
> Ulrich
>

That makes sense (actually, it calls for metadata.xml to be converted
to json even without bundling EAPI in there).

If repoman validated metadata.json based on a clear definition in PMS,
that would be a valid solution to the problem (that wouldn't require
external libraries beyond python)

Re: [gentoo-dev] RFD : .ebuild is only bash

[Alec Warner]

On Mon, Mar 12, 2012 at 3:06 PM, James Broadhead
<jamesbroadhead@gmail.com> wrote:
> On 12 March 2012 21:14, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>>>>> On Mon, 12 Mar 2012, James Broadhead wrote:
>>
>>> I'm sure that it's been considered already, but what are the arguments
>>> against embedding the EAPI on a per-package (default) or per-version
>>> basis in metadata.xml. It IS metadata after all.
>>
>> You can find a recent discussion in bug 402167, comment #4 and
>> following. <https://bugs.gentoo.org/show_bug.cgi?id=402167#c4>
>>
>> Ulrich
>>
>
> That makes sense (actually, it calls for metadata.xml to be converted
> to json even without bundling EAPI in there).
>
> If repoman validated metadata.json based on a clear definition in PMS,
> that would be a valid solution to the problem (that wouldn't require
> external libraries beyond python)
>

I'm not really convinced 'external libraries' is a critical problem;
it just seems like a nice thing to (try to) avoid.

-A

Re: [gentoo-dev] RFD : .ebuild is only bash

[Ciaran McCreesh]

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

On Mon, 12 Mar 2012 19:50:36 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:
> >>>>> On Mon, 12 Mar 2012, Ciaran McCreesh wrote:
> > GLEP 55 is simple, it solves all the problems we have (including the
> > version issue, which everyone is conveniently ignoring), it doesn't
> > require us to guess what's going to happen next and it can be
> > implemented immediately. That's a rather big deal.
> 
> The "header comment" solution solves all these issues too, without
> embedding unrelated information in the filename [1].

No it doesn't. See the "conveniently ignoring" part you're conveniently
ignoring.

> It can be implemented immediately, too.

No it can't, since existing package managers don't handle it.

> The argument that was always used against such solutions was that
> it would "hurt performance". However, when the council asked for
> benchmarks that would prove that point, nobody could provide them.

No, the argument was that such solutions didn't solve the full problem.
Performance issues were secondary, and were picked up upon as a way of
avoiding the whole "nothing else solves all the problems" thing.

> [1] <http://en.wikipedia.org/wiki/Filename> "The filename is metadata
> about a file; a string used to uniquely identify a file stored on the
> file system."

By that argument, there's no point in having a ".ebuild" there either.
Please don't continue the bad trend of posting irrelevant Wikipedia
links as footnotes as though the primary issue should be anything other
than a comparison of solutions to a technical problem [1].

[1] http://en.wikipedia.org/wiki/Spork

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFD : .ebuild is only bash

[Ulrich Mueller]

>>>>> On Mon, 12 Mar 2012, Ciaran McCreesh wrote:

> Ulrich Mueller <ulm@gentoo.org> wrote:
>> The "header comment" solution solves all these issues too, without
>> embedding unrelated information in the filename [1].

>> It can be implemented immediately, too.

> No it can't, since existing package managers don't handle it.

It can be easily implemented in a way that existing package managers
would mask the ebuild by unrecognised EAPI. At least if we stay with
bash, and nobody expects that we switch to any other format within the
next few years.

>> The argument that was always used against such solutions was that
>> it would "hurt performance". However, when the council asked for
>> benchmarks that would prove that point, nobody could provide them.

> No, the argument was that such solutions didn't solve the full
> problem. Performance issues were secondary, and were picked up upon
> as a way of avoiding the whole "nothing else solves all the
> problems" thing.

The performance argument is in GLEP 55 itself:

| Easily fetchable EAPI inside the ebuild
|
| Properties:
|    Can be used right away: no
|    Hurts performance: yes

Ulrich

Re: [gentoo-dev] RFD : .ebuild is only bash

[Ciaran McCreesh]

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

On Mon, 12 Mar 2012 20:38:21 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:
> The performance argument is in GLEP 55 itself:
> 
> | Easily fetchable EAPI inside the ebuild
> |
> | Properties:
> |    Can be used right away: no
> |    Hurts performance: yes

Sure. And it's a benefit, if your package mangler is carefully
designed to avoid doing unnecessary I/O. It's just not the primary
point. The primary point is that it handles whatever we feel like doing
in the future, even the "conveniently ignoring" stuff that you're
conveniently ignoring.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFD : .ebuild is only bash

[Brian Harring]

On Mon, Mar 12, 2012 at 07:50:36PM +0100, Ulrich Mueller wrote:
> >>>>> On Mon, 12 Mar 2012, Ciaran McCreesh wrote:
> > GLEP 55 is simple, it solves all the problems we have (including the
> > version issue, which everyone is conveniently ignoring), it doesn't
> > require us to guess what's going to happen next and it can be
> > implemented immediately. That's a rather big deal.
> 
> The "header comment" solution solves all these issues too, without
> embedding unrelated information in the filename [1]. It can be
> implemented immediately, too.
> 
> The argument that was always used against such solutions was that
> it would "hurt performance". However, when the council asked for
> benchmarks that would prove that point, nobody could provide them.

Just a note... it's effectively background noise if implemented even 
halfway sanely, and that's clocking it from w/in pkgcore; for portage, 
it will be purely in the noise.

That's not to say it's *efficient*- it's just not a real world 
performance concern.
~brian

Re: [gentoo-dev] RFD : .ebuild is only bash

[Patrick Lauer]

On 03/13/12 02:28, Ciaran McCreesh wrote:
[snip lots of political rhetoric]
> 
> GLEP 55 is simple,
No.

> it solves all the problems we have
No, it just tries to shove them under the carpet

> (including the
> version issue, which everyone is conveniently ignoring),
Say what?

> it doesn't require us to guess what's going to happen next and it can be
> implemented immediately.
So can migrating the tree to posix-only "ebuilds", but at what cost, and
what do we gain from it?

> That's a rather big deal.
So is switching to Arch Linux.


... why would we want to do such things?!

Re: [gentoo-dev] RFD : .ebuild is only bash

[Kent Fredric]

On 13 March 2012 07:17, Ulrich Mueller <ulm@gentoo.org> wrote:
>
> Note the smiley in my posting. And yes, it _is_ ugly.
>

It may be ugly, but I'll take ugly over "doesn't work" and "serious
technical limitations" any day ;)

Binary executables are "ugly", you don't see many people complaining ;)


-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

Re: [gentoo-dev] RFD : .ebuild is only bash

[Brian Harring]

On Mon, Mar 12, 2012 at 07:17:31PM +0100, Ulrich Mueller wrote:
> >>>>> On Mon, 12 Mar 2012, Ciaran McCreesh wrote:
> 
> > On Mon, 12 Mar 2012 19:00:32 +0100
> > Ulrich Mueller <ulm@gentoo.org> wrote:
> >> >>>>> On Mon, 12 Mar 2012, Zac Medico wrote:
> >> > If we do go with a variant of GLEP 55, I'd prefer a variant that
> >> > uses a constant extension (like .eb) and places the EAPI string
> >> > just after the version component of the name. For example:
> >> 
> >> >    foo-1.0-r1-eapi5.ebuild
> >> 
> >> This is so ugly... I guess I'll retire the same day when such an
> >> abomination gets accepted. ;-)
> 
> > I'm sorry, we're down to "it's ugly and someone already said no and
> > I'll throw my toys out of the pram if I don't get my way" as the
> > arguments against GLEP 55 now?
> 
> Note the smiley in my posting. And yes, it _is_ ugly.

Worse, it actually makes parsing _worse_ than it already is.  What G55 
had going for it was ease of filtering out unsupported eapi's.  
Literally just filter the readdir results.  This behemoth Zac is 
proposing basically requires throwing regex at it, and *is* able to 
be tripped up since eapi's aren't strictly integers (1-prefix, 
4-python, 4-eapi3 if I wanted to intentionally be a dick and break 
likely non-greedy implementations of the regex).

Same angle, embedding it into the version space means that there can 
be conflicts w/ PN.

Basically... embedding it into the versioning like that, besides being 
ugly as all hell, discards the main benefit g55 had- clear 
identification of EAPI.

It ain't worth it.

~brian

Re: [gentoo-dev] RFD : .ebuild is only bash

[Kent Fredric]

On 13 March 2012 17:31, Brian Harring <ferringb@gmail.com> wrote:
> Worse, it actually makes parsing _worse_ than it already is.  What G55
> had going for it was ease of filtering out unsupported eapi's.
> Literally just filter the readdir results.  This behemoth Zac is
> proposing basically requires throwing regex at it, and *is* able to
> be tripped up since eapi's aren't strictly integers (1-prefix,
> 4-python, 4-eapi3 if I wanted to intentionally be a dick and break
> likely non-greedy implementations of the regex).

Eh? How? If you make "." a forbidden character in an eapi
specificiation, and make "." the delimiter

  dev-foo/foo-bar-2.3.4.eapi5.eb

^^^^

How does that require regex?

remove the .eb  , and the last token remaining is the eapi .

it doesn't clash with the existing system for 2 reasons, 1) the .eb
extension   and 2)  "eapi5" is not a valid version token

> Same angle, embedding it into the version space means that there can
> be conflicts w/ PN.

I'm confused as to how, can you give one theoretical example?

  dev-foo/foo-bar-2.3.4.eapi5.eb  <-- eapi5 can't be a package name
here, because its got the .eb suffix which means an EAPI *MUST* be
specified

and eapi5 also can't be a package name there, because then you're
telling be it tokenizes as:

    category=dev-foo
    package=foo-bar-2.3.4.eapi5
    version  = undefined
    eapi      = undefined

Which is clearly illegal.

> Basically... embedding it into the versioning like that, besides being
> ugly as all hell, discards the main benefit g55 had- clear
> identification of EAPI.

It still seems "clear" to me.

-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

Re: [gentoo-dev] RFD : .ebuild is only bash

[Brian Harring]

On Tue, Mar 13, 2012 at 06:14:23PM +1300, Kent Fredric wrote:
> On 13 March 2012 17:31, Brian Harring <ferringb@gmail.com> wrote:
> > Worse, it actually makes parsing _worse_ than it already is. ??What G55
> > had going for it was ease of filtering out unsupported eapi's.
> > Literally just filter the readdir results. ??This behemoth Zac is
> > proposing basically requires throwing regex at it, and *is* able to
> > be tripped up since eapi's aren't strictly integers (1-prefix,
> > 4-python, 4-eapi3 if I wanted to intentionally be a dick and break
> > likely non-greedy implementations of the regex).
> 
> Eh? How? If you make "." a forbidden character in an eapi
> specificiation, and make "." the delimiter
> 
>   dev-foo/foo-bar-2.3.4.eapi5.eb
> 
> ^^^^
> 
> How does that require regex?

That works; note however that wasn't what was proposed. ;)

Still is god awfuly fugly though, and reliant on digits as the first 
character to be readable.  Consider exheres: 

dev-foo/foo-bar-2.3.4.eapiexheres.eb 

Or arfrever's personal EAPI: 

dev-foo/foo-bar-2.3.4.eapi4-python.eb 

Etc.  This isn't an improvement, it's a regression in readability 
bordering on intentionally hating the developer who has to deal with 
it.


> remove the .eb  , and the last token remaining is the eapi .
> 
> it doesn't clash with the existing system for 2 reasons, 1) the .eb
> extension   and 2)  "eapi5" is not a valid version token
> 
> > Same angle, embedding it into the version space means that there can
> > be conflicts w/ PN.
> 
> I'm confused as to how, can you give one theoretical example?

If you change the delimiter, it's not an issue; if it was left, 
consider dev-foo/blah-eapi2-1-eapi2.ebuild .  It's intentionally 
breaking it, but the point is that the issue *exists*, a problem that 
didn't before.  Change the delimiter and you can duck most of it 
although I suspect there still is a naggle or two.

That doesn't make parsing any prettier to implement however.


>   dev-foo/foo-bar-2.3.4.eapi5.eb  <-- eapi5 can't be a package name
> here, because its got the .eb suffix which means an EAPI *MUST* be
> specified
> 
> and eapi5 also can't be a package name there, because then you're
> telling be it tokenizes as:
> 
>     category=dev-foo
>     package=foo-bar-2.3.4.eapi5
>     version  = undefined
>     eapi      = undefined
> 
> Which is clearly illegal.

Just a general point.  You changed the delimiter- meaning the 
failures mostly go away.  My points were against Zac's original 
proposal, thus arguing those points don't actually exist (swapping the 
delimiter) is a bit of a wrong way to argue- argue "change the 
delimiter and it goes away" rather than "nuh uh, there isn't an 
issue".  Way less confusing.


> > Basically... embedding it into the versioning like that, besides being
> > ugly as all hell, discards the main benefit g55 had- clear
> > identification of EAPI.
> 
> It still seems "clear" to me.

"clear" means different things to different people.  For example, this 
code is actually clear to me:

class MockObject(dict):
  locals().update(
    ('__%sattr__' % x, getattr(dict, '__%sitem__' % x) for x in
    ('get', 'set', 'del'))

That code for everyone else is basically akin to eye-gouging w/ a 
follow up diddling of the new hole.  'Clear' is quite subjective being 
hte point.

EAPI mechanisms have to be designed for functionality, *and* ease of 
use for the general dev populace.  Having 

sys-apps/paludis-0.72.0-eapiexheres.ebuild

is *not* clearly parsable by the majority.  Were it parsable for the 
masses, that doesn't make it anything less than butt-fugly in my view.

If you really think it's great, convince others.  Ulm/Myself seem to 
view it fairly negatively, and I strongly doubt you're going to 
convince either of us to change those views.

~brian

Re: [gentoo-dev] RFD : .ebuild is only bash

[Wulf C. Krueger]

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

On 13.03.2012 07:22, Brian Harring wrote:
> Still is god awfuly fugly though, and reliant on digits as the first 
> character to be readable.  Consider exheres: 
> dev-foo/foo-bar-2.3.4.eapiexheres.eb 

Just for the record, your example is wrong. For exheres, it would be

foo-bar-2.3.4.exheres-0

"0" being the version. Simple, elegant, works.

Now please go on looking for a solution that takes (much) more effort
and/or is more complicated as it suits my personal goals better if you
choose something different, e. g. some kind of ebuild parsing. :-)

Best regards, Wulf


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

Re: [gentoo-dev] RFD : .ebuild is only bash

[Brian Harring]

On Tue, Mar 13, 2012 at 05:10:14PM +0100, Wulf C. Krueger wrote:
> On 13.03.2012 07:22, Brian Harring wrote:
> > Still is god awfuly fugly though, and reliant on digits as the first 
> > character to be readable.  Consider exheres: 
> > dev-foo/foo-bar-2.3.4.eapiexheres.eb 
> 
> Just for the record, your example is wrong. For exheres, it would be
>
> foo-bar-2.3.4.exheres-0
> 
> "0" being the version. Simple, elegant, works.

The example was right; you just didn't bother to read the thread.  

The proposal was to jam EAPI into the version namespace, rather than 
extension.  Meaning they're proposing that foo-bar example be

foo-bar-2.3.4.eapiexheres-0.ebuild

As I said in the email you didn't bother to actually read, such a 
proposal is fairly whacked and takes away the actual benefits of G55; 
aka, do G55 before doing that attrocity.

I'll skip replying to the rest of the snark in the email; I will 
however point out that toolish behaviour like above doesn't do G55 any 
favors in trying to reverse 5 years of people saying "I don't like the 
aesthetics".

That said, feel free to keep screaming into the wind about it.

~harring

[gentoo-dev] Re: RFD : .ebuild is only bash

[Duncan]

Kent Fredric posted on Tue, 13 Mar 2012 18:14:23 +1300 as excerpted:

> Eh? How? If you make "." a forbidden character in an eapi
> specificiation,
> and make "." the delimiter
> 
>   dev-foo/foo-bar-2.3.4.eapi5.eb
> 
> ^^^^
> 
> How does that require regex?
> 
> remove the .eb  , and the last token remaining is the eapi .
> 
> it doesn't clash with the existing system for 2 reasons, 1) the .eb
> extension   and 2)  "eapi5" is not a valid version token

That's logical, but as pointed out, the originally proposed delimiter was 
-, so dev-foo/foo-bar-2.3.4-eapi5.eb, which is a bit different.

I've wondered about other delimiters, too.  : seems obvious, but also 
rather likely to screw stuff up.  What about something like ^ :
dev-foo/foo-bar-2.3.4^eapi5.eb ? Or +  dev-foo/foo-bar-2.3.4+eapi5.eb ?


But my real reason for this post, and mostly picking your post to reply 
to as it's a convenient demonstration of .eb...

Someone raised the point about "eb" being taken as a swear word in 
Russian.  That might not be enough to derail it as the only choice, just 
as .fuck if it was the only thing available shouldn't be derailed, but 
surely there's other possible choices that aren't so objectionable.

I haven't seen these suggested yet:

.ebld .ebd .bld .dliube (backward, like xvid/vidx) .dlbe .be (ok, that's 
a 2-letter national code, but is it a swear word anywhere? if not I'd say 
it's still better).

We could even do an inside joke on eb/ebb and make it .flow ... or for 
that matter, .eflow or .ebflow =:^)

Some of those might have their own negative connotations or indeed, 
simply look too ugly, but that's the reason I'm asking.

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

Re: [gentoo-dev] RFD : .ebuild is only bash

[Michał Górny]

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

On Mon, 12 Mar 2012 10:22:57 -0700
Zac Medico <zmedico@gentoo.org> wrote:

> On 03/12/2012 10:12 AM, Ciaran McCreesh wrote:
> > On Mon, 12 Mar 2012 18:05:46 +0100
> > Ulrich Mueller <ulm@gentoo.org> wrote:
> >> See above, even if we should ever move away from bash, GLEP 55 is
> >> still not needed.
> > 
> > ...but we might as well go with GLEP 55 anyway, since GLEP 55
> > definitely works, whereas other solutions might work so long as we
> > don't do something unexpected.
> > 
> > This whole thing is just an exercise in trying to find excuses not
> > to use GLEP 55.
> 
> If we do go with a variant of GLEP 55, I'd prefer a variant that uses
> a constant extension (like .eb) and places the EAPI string just after
> the version component of the name. For example:
> 
>    foo-1.0-r1-eapi5.ebuild

Or .eapi5.ebuild, to make it more of a suffix and less of PV part.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] RFD : .ebuild is only bash

[Ulrich Mueller]

>>>>> On Mon, 12 Mar 2012, Ciaran McCreesh wrote:

> On Mon, 12 Mar 2012 18:05:46 +0100
> Ulrich Mueller <ulm@gentoo.org> wrote:
>> See above, even if we should ever move away from bash, GLEP 55 is
>> still not needed.

> ...but we might as well go with GLEP 55 anyway, since GLEP 55
> definitely works, whereas other solutions might work so long as we
> don't do something unexpected.

> This whole thing is just an exercise in trying to find excuses not
> to use GLEP 55.

There are very good reasons not to embed this information in the
filename. That it makes the filename harder to parse for the human eye
and more difficult to type is one of them.

Besides, we already have a council decision about that GLEP.

Ulrich

Re: [gentoo-dev] RFD : .ebuild is only bash

[Kent Fredric]

On 13 March 2012 06:53, Ulrich Mueller <ulm@gentoo.org> wrote:
>
> There are very good reasons not to embed this information in the
> filename. That it makes the filename harder to parse for the human eye
> and more difficult to type is one of them.
>
> Besides, we already have a council decision about that GLEP.

Difficulty in typing them is not really much of an argument,
considering the present complexity with file-names already having
versions encoded in them.

And difficulty reading them isn't much of an argument really either.

But difficulty identifying the format systematically seems a
reasonable enough objection, and for this, I can see the translation
of

abz-123.ebuild-5  to  ->  abz-123.eapi5.eb

Being a more practical change ( or something of that nature ).

At least that way, its easier to have a way to find "all ebuilds"
without needing extension permutation.

Another thought: Presently we have versions encoded in the file name.
If we ever decide we need to change our versioning syntax or
versioning semantics, we might be up the creek without a paddle, and
EAPI being *in* the file will probably make that harder, and I'd
probably prefer some sort of out-of-band location for EAPI in that
situation too.

-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

Re: [gentoo-dev] RFD : .ebuild is only bash

[Patrick Lauer]

On 03/13/12 01:12, Ciaran McCreesh wrote:
> On Mon, 12 Mar 2012 18:05:46 +0100
> Ulrich Mueller <ulm@gentoo.org> wrote:
>> See above, even if we should ever move away from bash, GLEP 55 is
>> still not needed.
> 
> ...but we might as well go with GLEP 55 anyway, since GLEP 55
> definitely works, whereas other solutions might work so long as we
> don't do something unexpected.
> 
> This whole thing is just an exercise in trying to find excuses not to
> use GLEP 55.
> 

That kind of circular reasoning makes my head hurt.

We discussed that ... topic ... to death about three times over the last
2 years, and the same arguments still apply.

Put an EAPI-marker in a well-defined position near the top of the
ebuild, problem solved. If it needs more it's not an ebuild anymore and
we should consider fixing all the other annoying glitches we have at the
same time, which causes a backwards-incompatible tree format change,
which means we need to plan the whole thing properly.

Trying to nail on GLEP55 is just trying to fix issues arising from not
fixing issues properly, so *if* we want to change things for no apparent
reason we should change them properly.

Re: [gentoo-dev] RFD : .ebuild is only bash

[Walter Dnes]

On Mon, Mar 12, 2012 at 05:12:28PM +0000, Ciaran McCreesh wrote

> This whole thing is just an exercise in trying to find excuses not to
> use GLEP 55.

  A filename should not be (ab)used as a database.  The main argument for
GLEP 55 is that it would make ebuild-processing generic.  I.e. making
ebuild info available to whatever future ebuild processor replacement
for bash was used.  A couple of comments...

1) Let's talk generic.  Right now, we're talking about EAPI.  In future,
what other (meta)data and characteristics will we need to know?  What
else will be tacked onto the filename?  EAPI, and any other critical
(meta)data should be declared early on in the ebuild.  That's what the
ebuild is for.

2) Any potential ebuild processor that's incapable of looking for regex
"^EAPI=" in a textfile, amd parsing the numbers that follow, has no
business being used to process ebuilds.

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-dev] RFD : .ebuild is only bash

[Kent Fredric]

On 13 March 2012 19:41, Walter Dnes <waltdnes@waltdnes.org> wrote:
> On Mon, Mar 12, 2012 at 05:12:28PM +0000, Ciaran McCreesh wrote
>
>> This whole thing is just an exercise in trying to find excuses not to
>> use GLEP 55.
>
>  A filename should not be (ab)used as a database.  The main argument for
> GLEP 55 is that it would make ebuild-processing generic.  I.e. making
> ebuild info available to whatever future ebuild processor replacement
> for bash was used.  A couple of comments...
>
> 1) Let's talk generic.  Right now, we're talking about EAPI.  In future,
> what other (meta)data and characteristics will we need to know?  What
> else will be tacked onto the filename?  EAPI, and any other critical
> (meta)data should be declared early on in the ebuild.  That's what the
> ebuild is for.
>
> 2) Any potential ebuild processor that's incapable of looking for regex
> "^EAPI=" in a textfile, amd parsing the numbers that follow, has no
> business being used to process ebuilds.
>


Yeah, the only other concept I wanted to see addressed for technical
concerns is a per-package metadata file ( that is *not* metadata.xml )
that intends to associate out-of-band metadata with files in the
package's directory.

Consider  if it were in .json , just for ease of explaining the concept

category/package/
    package-foo-1.2.ebuild
    package-foo-1.2.3.ebuild
    metamap.json

And in metamap.json :

{
    "_metamap" : {  "api-version" : 1 },
    "package-foo-1.2.ebuild" : {   "eapi" : "6" },
    "package-foo-1.2.3.ebuild" : { "eapi" : "7" }
}

Yes, I'm aware this imposes some limitations on editing files somewhat.

But I don't think I've seen this specific concept has seen a proper
fleshing out/destruction yet.

Really, I've seen lots of interesting ideas thus far, but I'm having
trouble keeping the pros / cons of each variant of each approach in my
head, and Glep55 wins by default because it fits better in my
short-term-memory =).

( Yes, yes, I stuck a _metamap key with attached _metamap api version
subkey *just* in case the format of the metamap needs to change.  If
you want to have a metametamap, well, I guess thats why we have
hallucinogens ;) )

-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

Re: [gentoo-dev] RFD : .ebuild is only bash

[Brian Harring]

On Tue, Mar 13, 2012 at 02:41:13AM -0400, Walter Dnes wrote:
> On Mon, Mar 12, 2012 at 05:12:28PM +0000, Ciaran McCreesh wrote
> 
> > This whole thing is just an exercise in trying to find excuses not to
> > use GLEP 55.
> 
>   A filename should not be (ab)used as a database.  The main argument for
> GLEP 55 is that it would make ebuild-processing generic.  I.e. making
> ebuild info available to whatever future ebuild processor replacement
> for bash was used.  A couple of comments...
> 
> 1) Let's talk generic.  Right now, we're talking about EAPI.  In future,
> what other (meta)data and characteristics will we need to know?  What
> else will be tacked onto the filename?  EAPI, and any other critical
> (meta)data should be declared early on in the ebuild.  That's what the
> ebuild is for.
> 
> 2) Any potential ebuild processor that's incapable of looking for regex
> "^EAPI=" in a textfile, amd parsing the numbers that follow, has no
> business being used to process ebuilds.

Perfectly valid, if stupid, bash:

EAPI=3
EAPI=4

Which is the PM to choose?  Because if your answer is "the first", 
then you need to keep in mind that any following code (including 
eclasses that test eapi) will be seeing the second during sourcing.  
Nice little gotcha, that one.

I'm aware people have suggested "make EAPI readonly" to try and deal 
w/ this; that however means it'll break any PM that uses eval for 
loading the ebuild, and means that every ebuild sourcing for phase 
running will throw a complaint about EAPI being readonly.

I don't hugely expect PMs to screw up the ordering of which to chose, 
although it exists; trying to ban secondary settings is also an 
approach... but all of it points to the fact it's a fricking hack and 
isn't really worth doing.

If we're going to redo EAPI, redo it right.  Don't half ass it- this 
time around we're not forced to make compromises.

Viewing it that way, this grep hack shouldn't be on the table as a
viable option.

~harring

Re: [gentoo-dev] RFD : .ebuild is only bash

[Ulrich Mueller]

>>>>> On Tue, 13 Mar 2012, Brian Harring wrote:

> Perfectly valid, if stupid, bash:

> EAPI=3
> EAPI=4

> Which is the PM to choose?  Because if your answer is "the first", 
> then you need to keep in mind that any following code (including 
> eclasses that test eapi) will be seeing the second during sourcing.  
> Nice little gotcha, that one.

> I'm aware people have suggested "make EAPI readonly" to try and deal 
> w/ this; that however means it'll break any PM that uses eval for 
> loading the ebuild, and means that every ebuild sourcing for phase 
> running will throw a complaint about EAPI being readonly.

For the moment, let's assume that we go that route and specify the
EAPI in a comment in the first line of the ebuild. The EAPI variable
can be made readonly if we do one of the following:

- One time change of the ebuild's extension, so old package managers
  won't see the new ebuilds.

- Specify the EAPI in the header, plus an assignment that is only seen
  by old package managers (that don't get the EAPI variable from the
  ebuild's header). All of the following should work:
     : ${EAPI=5}
     : ${EAPI=unsupported}
     [[ ${EAPI} ]] || EAPI=-1
  Any value for the EAPI can be used, as long as it's unknown to old
  package managers.

- A variant of the above, if an EAPI would add features that make
  sourcing of the ebuild with old package managers impossible:
     [[ ${EAPI} ]] || { EAPI=-1; return; }

  Testing this with current Portage (2.1.10.49) and two test ebuilds,
  app-misc/foo-1 is EAPI 4, app-misc/foo-2 contains the above line:

     # emerge -p app-misc/foo

     These are the packages that would be merged, in order:

     Calculating dependencies... done!
     [ebuild  N     ] app-misc/foo-1 

  foo-2 is masked by its unknown EAPI. No further warnings for the
  user.

  If I try to force installation of foo-2, I get the following:

     # emerge -p =app-misc/foo-2

     These are the packages that would be merged, in order:

     Calculating dependencies... done!

     !!! All ebuilds that could satisfy "=app-misc/foo-2" have been masked.
     !!! One of the following masked packages is required to complete your
     !!! request:
     - app-misc/foo-2::x-ulm (masked by: missing keyword, invalid: SLOT: invalid value: '', SLOT: undefined)

     The current version of portage supports EAPI '4'. You must upgrade to a
     newer version of portage before EAPI masked packages can be installed.
     For more information, see the MASKED PACKAGES section in the emerge
     man page or refer to the Gentoo Handbook.

  One line of spurious warnings because of missing KEYWORDS and SLOT,
  because the ebuild returns before these lines can be assigned.
  Otherwise, a clear message that the user should upgrade Portage.

  (Arguably, adding a line like [[ ${EAPI} ]] || { EAPI=-1; return; }
  to ebuilds wouldn't look elegant. See the above as proof of concept
  that a readonly EAPI variable is possible.)

> I don't hugely expect PMs to screw up the ordering of which to
> chose, although it exists; trying to ban secondary settings is also
> an approach... but all of it points to the fact it's a fricking hack
> and isn't really worth doing.

> If we're going to redo EAPI, redo it right.  Don't half ass it- this 
> time around we're not forced to make compromises.

> Viewing it that way, this grep hack shouldn't be on the table as a
> viable option.

Agreed, it's a hack if we try parsing the bash assignment statement.
I don't see it as a hack if we have a well defined syntax for the
ebuild's first line.

Ulrich

Re: [gentoo-dev] RFD : .ebuild is only bash

[Zac Medico]

On 03/13/2012 12:03 AM, Brian Harring wrote:
> On Tue, Mar 13, 2012 at 02:41:13AM -0400, Walter Dnes wrote:
>> 2) Any potential ebuild processor that's incapable of looking for regex
>> "^EAPI=" in a textfile, amd parsing the numbers that follow, has no
>> business being used to process ebuilds.
> 
> Perfectly valid, if stupid, bash:
> 
> EAPI=3
> EAPI=4
> 
> Which is the PM to choose?  Because if your answer is "the first", 
> then you need to keep in mind that any following code (including 
> eclasses that test eapi) will be seeing the second during sourcing.  
> Nice little gotcha, that one.
> 
> I'm aware people have suggested "make EAPI readonly" to try and deal 
> w/ this; that however means it'll break any PM that uses eval for 
> loading the ebuild, and means that every ebuild sourcing for phase 
> running will throw a complaint about EAPI being readonly.
> 
> I don't hugely expect PMs to screw up the ordering of which to chose, 
> although it exists; trying to ban secondary settings is also an 
> approach... but all of it points to the fact it's a fricking hack and 
> isn't really worth doing.
> 
> If we're going to redo EAPI, redo it right.  Don't half ass it- this 
> time around we're not forced to make compromises.

The "parse EAPI assignment" approach is more about fixing EAPI than
redoing it. It's the least invasive approach, and it would work
perfectly well in practice. Issues like the invalid double assignment
that you mentioned, which are pretty unlikely anyway, are easily handled
if package manager implements a feedback mechanism to assert that the
parsed EAPI is identical to the value obtained from bash [1].

[1] https://bugs.gentoo.org/show_bug.cgi?id=402167#c18
-- 
Thanks,
Zac

Re: [gentoo-dev] RFD : .ebuild is only bash

[Ciaran McCreesh]

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

On Tue, 13 Mar 2012 02:41:13 -0400
"Walter Dnes" <waltdnes@waltdnes.org> wrote:
> On Mon, Mar 12, 2012 at 05:12:28PM +0000, Ciaran McCreesh wrote
> > This whole thing is just an exercise in trying to find excuses not
> > to use GLEP 55.
> 
>   A filename should not be (ab)used as a database.

You mean we shouldn't have name, version and format in there? Because
those are there already. All GLEP 55 does is make the format part more
specific.

> 1) Let's talk generic.  Right now, we're talking about EAPI.  In
> future, what other (meta)data and characteristics will we need to
> know?  What else will be tacked onto the filename?  EAPI, and any
> other critical (meta)data should be declared early on in the ebuild.
> That's what the ebuild is for.

EAPI is special. You need to know EAPI to be able to get the rest of
the metadata.

> 2) Any potential ebuild processor that's incapable of looking for
> regex "^EAPI=" in a textfile, amd parsing the numbers that follow,
> has no business being used to process ebuilds.

That doesn't get you the EAPI.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFD : .ebuild is only bash

[Walter Dnes]

On Tue, Mar 13, 2012 at 07:30:22AM +0000, Ciaran McCreesh wrote

> EAPI is special. You need to know EAPI to be able to get the rest of
> the metadata.
> 
> > 2) Any potential ebuild processor that's incapable of looking for
> > regex "^EAPI=" in a textfile, amd parsing the numbers that follow,
> > has no business being used to process ebuilds.
> 
> That doesn't get you the EAPI.

On Tue, Mar 13, 2012 at 12:03:34AM -0700, Brian Harring wrote

> Perfectly valid, if stupid, bash:
>
> EAPI=3
> EAPI=4
>
> Which is the PM to choose?  Because if your answer is "the first",
> then you need to keep in mind that any following code (including
> eclasses that test eapi) will be seeing the second during sourcing.
> Nice little gotcha, that one.
>
> I'm aware people have suggested "make EAPI readonly" to try and deal
> w/ this; that however means it'll break any PM that uses eval for
> loading the ebuild, and means that every ebuild sourcing for phase
> running will throw a complaint about EAPI being readonly.
>
> I don't hugely expect PMs to screw up the ordering of which to chose,
> although it exists; trying to ban secondary settings is also an
> approach... but all of it points to the fact it's a fricking hack and
> isn't really worth doing.

  I'm answering Ciaran's and Brian's posts together, because the answer
is the same for both... namely, we need a 2-pass processor, regardless
of whether it's bash/perl/python/whatever.  Pass 1 checks for syntax
errors and retrieves "special" variables, answering Ciaran's concern.
Today, it's EAPI.  In future, there may be others.  Pass 2 does the
build, assuming no errors detected in pass 1.

  Under the heading of "syntax errors", I would include multiple EAPI
declarations.  My response to Brian is that portage should not try to
outguess or fix or override an obviously broken ebuild.  It should
return an error message (in this case "Multiple EAPI declarations not
allowed") and then halt.  It is the ebuild-writer's job to come up with
a syntactically correct ebuild.

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-dev] RFD : .ebuild is only bash

[Michael Orlitzky]

On 03/13/2012 08:29 PM, Walter Dnes wrote:
>
>    I'm answering Ciaran's and Brian's posts together, because the answer
> is the same for both... namely, we need a 2-pass processor, regardless
> of whether it's bash/perl/python/whatever.  Pass 1 checks for syntax
> errors and retrieves "special" variables, answering Ciaran's concern.
> Today, it's EAPI.  In future, there may be others.  Pass 2 does the
> build, assuming no errors detected in pass 1.
>

Problem is, the only thing that can tell if there's a bash syntax error 
is bash itself.

Re: [gentoo-dev] RFD : .ebuild is only bash

[Brian Harring]

On Tue, Mar 13, 2012 at 08:29:03PM -0400, Walter Dnes wrote:
> On Tue, Mar 13, 2012 at 07:30:22AM +0000, Ciaran McCreesh wrote
> 
> > EAPI is special. You need to know EAPI to be able to get the rest of
> > the metadata.
> > 
> > > 2) Any potential ebuild processor that's incapable of looking for
> > > regex "^EAPI=" in a textfile, amd parsing the numbers that follow,
> > > has no business being used to process ebuilds.
> > 
> > That doesn't get you the EAPI.
> 
> On Tue, Mar 13, 2012 at 12:03:34AM -0700, Brian Harring wrote
> 
> > Perfectly valid, if stupid, bash:
> >
> > EAPI=3
> > EAPI=4
> >
> > Which is the PM to choose?  Because if your answer is "the first",
> > then you need to keep in mind that any following code (including
> > eclasses that test eapi) will be seeing the second during sourcing.
> > Nice little gotcha, that one.
> >
> > I'm aware people have suggested "make EAPI readonly" to try and deal
> > w/ this; that however means it'll break any PM that uses eval for
> > loading the ebuild, and means that every ebuild sourcing for phase
> > running will throw a complaint about EAPI being readonly.
> >
> > I don't hugely expect PMs to screw up the ordering of which to chose,
> > although it exists; trying to ban secondary settings is also an
> > approach... but all of it points to the fact it's a fricking hack and
> > isn't really worth doing.
> 
>   I'm answering Ciaran's and Brian's posts together, because the answer
> is the same for both... namely, we need a 2-pass processor, regardless
> of whether it's bash/perl/python/whatever.  Pass 1 checks for syntax
> errors and retrieves "special" variables, answering Ciaran's concern.
> Today, it's EAPI.  In future, there may be others.  Pass 2 does the
> build, assuming no errors detected in pass 1.

With respect, this statement carries no actual weight nor usefulness.  
PMs, by nature of dep resolution/building, already have that effective 
seperation.

The point of this whole discussion is how to get metadata out of the 
ebuild w/out excessive burdens on future formats.  This pass1/pass2 
doesn't address that at all, nor actually relevant to the discussion 
at hand.  Not trying to be a complete dick here, but you completely 
missed the points being discussed including actually responding to 
ciaran's point.

I suggest you grab the sources of whichever PM you use, and audit how 
it gets metadata- it would help for understanding and contributing to 
this discussion.  At the very least it would be useful having another 
person besides the Ulm/3 PM authors who actually are familiar w/ how 
this actually works at the core.


>   Under the heading of "syntax errors", I would include multiple EAPI
> declarations.  My response to Brian is that portage should not try to
> outguess or fix or override an obviously broken ebuild.  It should
> return an error message (in this case "Multiple EAPI declarations not
> allowed") and then halt.  It is the ebuild-writer's job to come up with
> a syntactically correct ebuild.

And it's the PMs responsibility to enforce the rules of the 
environment; there in is part of the problem- portage is generally 
pretty lax about any form of strictness there, and has historically 
been that way.  Even if one couldn't just point at portage, there 
still would be the problem of 3 different managers all needing to 
enforce the same tricky environment restrictions.

Leaving it such that the PM has to enforce things like "don't have 
multiple EAPI assignments" means by default, one of them isn't going 
to... leading to the ebuilds breaking... specifically the common case 
being the ebuild becoming acclimated to some quirk of portage.  EAPI 
was started to try and address that sensitivity (including rolling out 
new features), and the literal history of EAPI has involved dealing w/ 
quirks of portages past behaviour- including pre EAPI0.

Generally speaking, the less ways something can be screwed up means 
less ways something *will* be screwed up.

My point was that this can be pretty easily screwed up, and isn't as 
simple to enforce as people seem to think- that's not counting just 
flat out issues w/ the actual usage of it.

~brian

Re: [gentoo-dev] RFD : .ebuild is only bash

[Zac Medico]

On 03/13/2012 06:42 PM, Brian Harring wrote:
> Leaving it such that the PM has to enforce things like "don't have 
> multiple EAPI assignments" means by default, one of them isn't going 
> to... leading to the ebuilds breaking... specifically the common case 
> being the ebuild becoming acclimated to some quirk of portage.

My intention is for PMS to specify the search algorithm that's used to
probe the EAPI, and also for it to specify that package managers must
treat an ebuild as invalid if the probed EAPI is not identical to the
one that's obtained from bash. If all package managers adhere strictly
to these two requirements, then we won't have any incompatibilities
between package managers here.
-- 
Thanks,
Zac

Re: [gentoo-dev] RFD : .ebuild is only bash

[Michael Orlitzky]

On 03/13/2012 10:05 PM, Zac Medico wrote:
> On 03/13/2012 06:42 PM, Brian Harring wrote:
>> Leaving it such that the PM has to enforce things like "don't have
>> multiple EAPI assignments" means by default, one of them isn't going
>> to... leading to the ebuilds breaking... specifically the common case
>> being the ebuild becoming acclimated to some quirk of portage.
>
> My intention is for PMS to specify the search algorithm that's used to
> probe the EAPI, and also for it to specify that package managers must
> treat an ebuild as invalid if the probed EAPI is not identical to the
> one that's obtained from bash. If all package managers adhere strictly
> to these two requirements, then we won't have any incompatibilities
> between package managers here.

Someone should really throw up a table on wiki.g.o with a comparison of 
the proposed methods. IIRC, the pros/cons of this in contrast to GLEP 55 
are something like,

Pro:

  * We don't need to change the filename, and "ebuild" is nice
  * GLEP 55 pissed people off, and was already rejected
  * Some people think the EAPI rightfully belongs in the ebuild

Cons:

  * New features can't be implemented immediately because PMs
    have to catch up first.
  * Slight performance hit
  * Old package managers on out-of-date systems will barf on it
  * It involves using a magic identifier, e.g. a comment. Magic is
    bad, and the fact that messing with a comment can break your PM
    is counter-intuitive.
  * Some people think the EAPI rightfully belongs in the filename


and the last one is worth the most points to everyone anyway.

Re: [gentoo-dev] RFD : .ebuild is only bash

[Zac Medico]

On 03/13/2012 07:23 PM, Michael Orlitzky wrote:
> Someone should really throw up a table on wiki.g.o with a comparison of
> the proposed methods.

We've got one already:

http://wiki.gentoo.org/wiki/Alternate_EAPI_mechanisms

-- 
Thanks,
Zac

Re: [gentoo-dev] RFD : .ebuild is only bash

[Michael Orlitzky]

On 03/13/2012 10:36 PM, Zac Medico wrote:
> On 03/13/2012 07:23 PM, Michael Orlitzky wrote:
>> Someone should really throw up a table on wiki.g.o with a comparison of
>> the proposed methods.
>
> We've got one already:
>
> http://wiki.gentoo.org/wiki/Alternate_EAPI_mechanisms
>

*facepalm*

Re: [gentoo-dev] RFD : .ebuild is only bash

[Brian Harring]

On Tue, Mar 13, 2012 at 07:05:57PM -0700, Zac Medico wrote:
> On 03/13/2012 06:42 PM, Brian Harring wrote:
> > Leaving it such that the PM has to enforce things like "don't have 
> > multiple EAPI assignments" means by default, one of them isn't going 
> > to... leading to the ebuilds breaking... specifically the common case 
> > being the ebuild becoming acclimated to some quirk of portage.
> 
> My intention is for PMS to specify the search algorithm that's used to
> probe the EAPI, and also for it to specify that package managers must
> treat an ebuild as invalid if the probed EAPI is not identical to the
> one that's obtained from bash.

*Now* is when you should be applying your KISS wikipedia links 
(moreso, the principle applied to your proposal).

What you're talking about is requiring PMs to monitor what occured 
and bail- rather than precluding it from even occuring.  I repeat; try 
to spot the situation and make things blow up, rather than disallowing 
it from occuring in the first place.

It's really that simple; this is why the "grep the assignment" out of 
the source is at its core, a well intentioned but fundamentally bad 
idea.  It's glue on a bad situation rather than just removing the bad 
situation.


> If all package managers adhere strictly
> to these two requirements, then we won't have any incompatibilities
> between package managers here.

You're missing a lot of the point here; defining some search algo is 
basically screwed at its core due to the flexibility of bash.  Simple 
example:

if [ "$PV" -eq 9999 ]; then
EAPI=3
else
EAPI=2
fi

The flexibility of bash means that your attempt to enforce simplistic 
rules like "it must be greppable" are at loggerheads; if the rules 
were "last is the one thats used", then I just invert the if check.

Yep, the above is stupid code.  Frankly, the sort of stupid code 
I'd expect out of a newbie ebuild dev.  The EAPI bit there is 
synthetic, but that sort of construct (putting everything into a 
single file, then using symlinks to expose differing versions) is out 
in the wild and used.

The fact that potential exists is a flat out sign the approach is 
broken.   Worse, it's a way to trip up people- specifically new devs 
who don't know fun rules like "the PM has this lovely search algo for 
getting EAPI that you must abide by".

~brian

Re: [gentoo-dev] RFD : .ebuild is only bash

[Zac Medico]

On 03/13/2012 07:38 PM, Brian Harring wrote:
> On Tue, Mar 13, 2012 at 07:05:57PM -0700, Zac Medico wrote:
>> If all package managers adhere strictly
>> to these two requirements, then we won't have any incompatibilities
>> between package managers here.
> 
> You're missing a lot of the point here; defining some search algo is 
> basically screwed at its core due to the flexibility of bash.  Simple 
> example:
> 
> if [ "$PV" -eq 9999 ]; then
> EAPI=3
> else
> EAPI=2
> fi
> 
> The flexibility of bash means that your attempt to enforce simplistic 
> rules like "it must be greppable" are at loggerheads; if the rules 
> were "last is the one thats used", then I just invert the if check.
> 
> Yep, the above is stupid code.  Frankly, the sort of stupid code 
> I'd expect out of a newbie ebuild dev.  The EAPI bit there is 
> synthetic, but that sort of construct (putting everything into a 
> single file, then using symlinks to expose differing versions) is out 
> in the wild and used.
> 
> The fact that potential exists is a flat out sign the approach is 
> broken.   Worse, it's a way to trip up people- specifically new devs 
> who don't know fun rules like "the PM has this lovely search algo for 
> getting EAPI that you must abide by".

It won't be a problem because the package manager can reject the ebuild
as soon as the dev tries to execute it the first time, and it will refer
the dev to the section of PMS that specifies the search algorithm.

As for ebuilds in the wild that already do stuff like that, it's not a
problem if we only require the search algorithm to work starting with
EAPI 5.
-- 
Thanks,
Zac

Re: [gentoo-dev] RFD : .ebuild is only bash

[Ulrich Mueller]

>>>>> On Tue, 13 Mar 2012, Kent Fredric wrote:

> Is it really so fixed that ".ebuild" will only ever be bash ?

Certainly it would make sense to change the file extension when an
EAPI will require something different than bash. For example, some
editors (Emacs and XEmacs at least) recognise the .ebuild extension
and use corresponding syntax rules.

> If thats the case, then G55 ( or something similar ) is practically
> guaranteed as soon as we want something non-bash.

No, you just use a new extension once and you're done. And I guess
such drastic changes won't happen frequently. In the past 12 years
there hasn't been a single one. (If they will ever happen, this is a
pretty academic discussion.)

Ulrich

Re: [gentoo-dev] RFD : .ebuild is only bash

[Michał Górny]

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

On Tue, 13 Mar 2012 04:57:04 +1300
Kent Fredric <kentfredric@gmail.com> wrote:

> On 12 March 2012 22:37, Brian Harring <ferringb@gmail.com> wrote:
> > Ebuilds *are* bash.  There isn't ever going to be a PMS labeled
> > xml format that is known as ebuilds... that's just pragmatic reality
> > since such a beast is clearly a seperate format (thus trying to call
> > it an 'ebuild' is dumb, confusing, and counter productive).
> 
> 
> I think this notion should be concluded before we continue debating as
> to how best to implement EAPI declarations.
> 
> Is it really so fixed that ".ebuild" will only ever be bash ?
> 
> If thats the case, then G55 ( or something similar ) is practically
> guaranteed as soon as we want something non-bash.

Maybe instead of per-EAPI suffix change, we'd want to prepend the
suffix with something special whenever the actual format changes.

In other words, if EAPI 15 introduces XML-based syntax, we start
using .xml.ebuild. If EAPI 7 introduces bash4 in global scope (still
don't see much reason for it), we use .bash4.ebuild.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] RFD : .ebuild is only bash

[Richard Yao]

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

On 03/12/12 11:57, Kent Fredric wrote:
> On 12 March 2012 22:37, Brian Harring <ferringb@gmail.com> wrote:
>> Ebuilds *are* bash.  There isn't ever going to be a PMS labeled
>> xml format that is known as ebuilds... that's just pragmatic reality
>> since such a beast is clearly a seperate format (thus trying to call
>> it an 'ebuild' is dumb, confusing, and counter productive).
> 
> 
> I think this notion should be concluded before we continue debating as
> to how best to implement EAPI declarations.
> 
> Is it really so fixed that ".ebuild" will only ever be bash ?
> 
> If thats the case, then G55 ( or something similar ) is practically
> guaranteed as soon as we want something non-bash.
> 
> 
> 
> 
> --
> Kent
> 
> perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
> 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"
> 

I imagine that POSIX Shell is a possibility, although strict compliance
would mean abandoning a few extensions like the local keyword that are
probably rather useful in eclasses.

To make XML a viable substitute for bash, you will need to implement a
turing complete language in XML, which should probably preclude its use
in ebuilds. You would  likely have better luck with a functional
programming language, although you are more than welcome to demonstrate
otherwise.


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

Re: [gentoo-dev] RFD : .ebuild is only bash

[Rich Freeman]

On Tue, Mar 13, 2012 at 2:29 AM, Richard Yao <ryao@cs.stonybrook.edu> wrote:
> To make XML a viable substitute for bash, you will need to implement a
> turing complete language in XML, which should probably preclude its use
> in ebuilds. You would  likely have better luck with a functional
> programming language, although you are more than welcome to demonstrate
> otherwise.

Well, a trivial solution to that is to embed bash code (or some other
language) into the content of the xml file.  As I and others posted
earlier the advantage is that it makes all the key/value stuff easier
to manage than doing it in bash, but it makes editing the scripting
content harder and requires pre-processing before being fed into an
interpreter.

If you look at metadata.xml you could argue that we're already using
xml-based ebuilds to an extent, but we split the metadata across two
different files in different formats and call them different things.

In any case, my point in bringing up xml was that the whole point of
GLEP 55 was to future-proof the interpretation of ebuild files, and
xml is just one example of what the future could conceivably look
like.

Rich