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;
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... s
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*
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
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
bei
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
On Tue, Mar 13, 2012 at 08:29:03PM -0400, Walter Dnes wrote:
> On Tue, Mar 13, 2012 at 07:30:22AM +, 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
>
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
On Tue, Mar 13, 2012 at 07:30:22AM +, 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,
> >
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 t
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
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
"
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.
>
On Tue, Mar 13, 2012 at 2:29 AM, Richard Yao 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
> 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 dur
On Tue, 13 Mar 2012 02:41:13 -0400
"Walter Dnes" wrote:
> On Mon, Mar 12, 2012 at 05:12:28PM +, 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 n
On Tue, Mar 13, 2012 at 02:41:13AM -0400, Walter Dnes wrote:
> On Mon, Mar 12, 2012 at 05:12:28PM +, 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
On 13 March 2012 19:41, Walter Dnes wrote:
> On Mon, Mar 12, 2012 at 05:12:28PM +, 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
On Mon, Mar 12, 2012 at 05:12:28PM +, 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
eb
On 03/12/12 11:57, Kent Fredric wrote:
> On 12 March 2012 22:37, Brian Harring 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
>
On Tue, Mar 13, 2012 at 06:14:23PM +1300, Kent Fredric wrote:
> On 13 March 2012 17:31, Brian Harring 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.
> 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
On 13 March 2012 17:31, Brian Harring 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
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 wrote:
> >> > On Mon, 12 Mar 2012, Zac Medico wrote:
> >> > If we do go with a variant of GLEP 55, I'd prefer a varia
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
On 03/13/12 01:12, Ciaran McCreesh wrote:
> On Mon, 12 Mar 2012 18:05:46 +0100
> Ulrich Mueller 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 solu
On 12 March 2012 22:37, Kent Fredric 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-wo
On Mon, Mar 12, 2012 at 3:37 PM, Kent Fredric wrote:
> On 13 March 2012 11:02, Mike Gilbert 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 counc
On 13 March 2012 11:02, Mike Gilbert 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 tha
On Mon, Mar 12, 2012 at 3:06 PM, James Broadhead
wrote:
> On 12 March 2012 21:14, Ulrich Mueller 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 pe
On 12 March 2012 21:14, Ulrich Mueller 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.
>
On Mon, Mar 12, 2012 at 5:49 PM, Alec Warner wrote:
> On Mon, Mar 12, 2012 at 2:28 PM, Kent Fredric wrote:
>> On 13 March 2012 10:14, Ulrich Mueller wrote:
On Mon, 12 Mar 2012, James Broadhead wrote:
>>>
I'm sure that it's been considered already, but what are the arguments
ag
On Mon, Mar 12, 2012 at 2:28 PM, Kent Fredric wrote:
> On 13 March 2012 10:14, Ulrich Mueller 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-v
On 13 March 2012 10:14, Ulrich Mueller 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.
>
> 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, comm
On 12 March 2012 20:10, Ciaran McCreesh wrote:
> On Mon, 12 Mar 2012 20:49:22 +0100
> Ulrich Mueller 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.
>>
>> Thi
On Mon, 12 Mar 2012 20:49:22 +0100
Ulrich Mueller 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
> On Mon, 12 Mar 2012, Ciaran McCreesh wrote:
> On Mon, 12 Mar 2012 14:58:01 -0400
> Ian Stakenvicius 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
On Mon, 12 Mar 2012 20:38:21 +0100
Ulrich Mueller 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 careful
> On Mon, 12 Mar 2012, Ciaran McCreesh wrote:
> Ulrich Mueller 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 12 Mar 2012 14:58:01 -0400
Ian Stakenvicius 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
On Mon, 12 Mar 2012 19:50:36 +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 happ
-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 u
> 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 b
On 13 March 2012 07:17, Ulrich Mueller 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
On Mon, 12 Mar 2012 19:17:31 +0100
Ulrich Mueller 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
> On Mon, 12 Mar 2012, Ciaran McCreesh wrote:
> On Mon, 12 Mar 2012 19:00:32 +0100
> Ulrich Mueller 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
On Mon, 12 Mar 2012 19:00:32 +0100
Ulrich Mueller 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 exa
On 13 March 2012 06:53, Ulrich Mueller 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.
On Tue, 13 Mar 2012 04:57:04 +1300
Kent Fredric wrote:
> On 12 March 2012 22:37, Brian Harring 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 (
> 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
On Mon, 12 Mar 2012 10:22:57 -0700
Zac Medico wrote:
> On 03/12/2012 10:12 AM, Ciaran McCreesh wrote:
> > On Mon, 12 Mar 2012 18:05:46 +0100
> > Ulrich Mueller wrote:
> >> See above, even if we should ever move away from bash, GLEP 55 is
> >> still not needed.
> >
> > ...but we might as well go
> On Mon, 12 Mar 2012, Ciaran McCreesh wrote:
> On Mon, 12 Mar 2012 18:05:46 +0100
> Ulrich Mueller 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 oth
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 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 anywa
On Mon, 12 Mar 2012 13:17:15 -0400
Michael Orlitzky 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
On 03/12/2012 10:12 AM, Ciaran McCreesh wrote:
> On Mon, 12 Mar 2012 18:05:46 +0100
> Ulrich Mueller 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
On 03/12/12 13:12, Ciaran McCreesh wrote:
> On Mon, 12 Mar 2012 18:05:46 +0100
> Ulrich Mueller 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 solu
On Mon, 12 Mar 2012 18:05:46 +0100
Ulrich Mueller 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 unex
> 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
> 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 .e
On Mon, Mar 12, 2012 at 11:59 AM, Ciaran McCreesh
wrote:
> On Tue, 13 Mar 2012 04:57:04 +1300
> Kent Fredric 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
On Tue, 13 Mar 2012 04:57:04 +1300
Kent Fredric 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
On 12 March 2012 22:37, Brian Harring 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 coun
63 matches
Mail list logo
