Re: [gentoo-dev] The fallacies of GLEP55

[Arun Raghavan]

On Sat, 2009-05-16 at 20:21 +0100, Ciaran McCreesh wrote:
[...] 
> Can't do that. The package manager has to barf on unrecognised .ebuild
> files.

I assume the reasons are the same as below.

> > If this is not viable, make an unrecognised version string cause the
> > same fallback as an unsupported EAPI => ignore the ebuild. Again, fast
> > track to stable portage, and not so long after, you're done.
> 
> Again, no good. First, it means a year or more wait before doing
> anything. Second, it removes a whole level of error checking. Third, it
> means a package manager can't know what versions are available for a
> package without generating metadata for every potential version.

1) Why a year? I'd say 4-6 months after portage goes stable is fine.

2) Replace the errors with warnings. And these need to exist only at
'repoman manifest' time, so they're not end-user-visible (and don't need
to be).

-- Arun

3) This is again, when the metadata is uncached, which is not the normal
case and can be ignored. And the (minor) performance penalty in the
cached case, if any, is not reason enough to make this change.


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] The fallacies of GLEP55

[Richard Freeman]

Ciaran McCreesh wrote:

The only way it'll be "in the next ten years" rather than "in the next
two years" is if Gentoo continues its current approach of making
changes require every single person to agree...



Frankly, I won't be at all surprised if this thread (in some form) is 
still going on in the next two years, and nothing at all has been 
implemented.


As far as Gentoo requiring EVERY single person to agree - that is hardly 
the case.  But there does need to be a general consensus or some impetus 
for moving forward without one.  I don't really see either.


If consensus isn't necessary then I'll solve the whole debate for you 
now - EAPI goes on line 5 of the ebuild in the syntax EAPI=foo, and 
filenames remain as they are now.  There we are - done.  Now, lets go 
ahead and start implementing it so that in 6-12 months we can roll out 
new version numbering schemes.  Surely you're not suggesting that we 
shouldn't move forward with this merely because some people (like you) 
don't agree?


Since the inevitable reply is going to be that it isn't about consensus, 
but rather it is about merit - as the official arbiter of all things 
meritorious I hereby declare that my idea is the best one out there.


Now, back in the real world where neither of us is the dictator of 
Gentoo, I'm quite happy to wait for the Council to rule on this, or to 
choose to not rule on this.  Their reluctance to do so to date just 
reflects how divided the developer community is over the issue.

Re: [gentoo-dev] Re: The fallacies of GLEP55

[Richard Freeman]

Duncan wrote:
So I believe the cost to be quite reasonably managed, after all.  
Benchmarks would of course be needed to demonstrate that, but I believe 
it worth pursuing.




Agreed.  Perhaps I'm just spoiled by RDBMS's at work or something, but 
it seems like we're trying to squeeze every ounce of speed out of a 
non-indexed flat file database and do everything we can to avoid 
actually putting all that metadata in something that actually is 
queryable no matter how lousy the final design ends up being.


Expressing the package database as a set of flat files works nicely - 
especially with cvs/git/etc.  Actually working with that data directly 
on a real system doesn't make sense at all.  Index it once and then only 
open the flat files on the rare occasion that you actually need to 
install one of them.  Such an index can be centrally distributed, or it 
could be maintained as packages are rsynced (and of course users should 
be able to update it on demand as well).


When the speed of your package management system depends on the 
performance of find vs grep -r, you are doing something wrong.  Neither 
works all that well.

Re: [gentoo-dev] The fallacies of GLEP55

[Richard Freeman]

Ravi Pinjala wrote:

Nick Fortino wrote:

Such a transformation is possible, given the restrictions on arg, as
well as ebuild format.


Isn't this a bit circular? The whole point of wanting to change the
extension is to get rid of exactly these restrictions; if you assume the
restrictions, then the whole thing is kind of pointless. :)



What restrictions?  The restriction that EAPI be fixed on the 5th line 
of the build, or the restriction that EAPI be fixed in the filename.  I 
don't really see much difference between them.  What can the one do that 
the other can't.


The only thing that has been suggested is changing the package 
versioning scheme.  That is handled in a straightforward way - parse the 
EAPI before you try to extract the version from the filename.  Sure, 
that isn't compatible with older versions of portage, but if we start 
now I'm sure we can get there in the reasonably near future.


Personally, I'm not a fan of parsing ANYTHING out of the filename. 
Sure, keep the file naming convention for the sake of convenience, but I 
think a better design would be to field everything inside the file - 
including category, packagename, and version.  Then you no longer have 
to worry about whether a given hyphen is a separator or part of one of 
the components (among other things).  Sure, you can't just bump an 
ebuild by renaming it, but if we had been doing it this way all along 
then the versioning issue we're debating now would be a non-issue.

[gentoo-dev] Re: The fallacies of GLEP55

[Mark Bateman]

Ciaran McCreesh  googlemail.com> writes:

> 
> On Sat, 16 May 2009 21:58:10 + (UTC)
> Mark Bateman  soon.com> wrote:
> > "The current way of specifying the EAPI in ebuilds is flawed"
> > That is not defining the problem, that is an opening statement.
> 
> That is the problem.
No, that is a summary of the problem. Not once has the actual problem been 
described or documented. It has been requested multiple times by multiple 
people and yet a description detailing the problem has yet to materialise.
Repeated use of *problem* doesn't suddenly expand on the definition of the word 
*problem* to encompass details needed in a technical proposal within a GLEP.
If you do not understand the problems associated with determining the EAPI of 
an ebuild before sourcing it, please stop championing this GLEP until someone 
does provide a complete breakdown of the process.

Until such information is provided continued discussion of this GLEP is not 
going to progress since words like *obviously* are substituted for actual 
facts, a substitution which does not provide anything new to this discussion
 
> > "In order to get the EAPI the package manager needs to source the
> > ebuild, which itself needs the EAPI in the first place."
> > It then describes "a" mechanism utilising an ebuild
> > (source /usr/portage...) to obtain the EAPI from within the ebuild
> > (EAPI=...). Using this method the entire content of GLEP55 is
> > accurate. 
> > 
> > However, this is not the only method to determine the EAPI of an
> > ebuild that exists and as such the viability of GLEP55 as the best
> > solution is brought into question
> 
> Yes, it is the only method.
No it is the only method you are willing to accept, there is a big difference. 
Many people have mentioned in passing other means of determining the EAPI of 
an ebuild pre-sourcing (thus allowing the PM to source the correct eclass
or flag up warnings...) YET they have just been shot down with no 
actual technical reason, except "they do not involve coding the EAPI 
into the filename". Please provide detailed technical description of 
the problem, as has been requested by a number of people, as well as 
providing details of why in-filename encoding of EAPI is technically 
as well as practically the best solution.



> 
> > Where is it defined that the ebuild must be sourced 1st?
> > Why does the ebuild have to be sourced 1st?
> 
> Such things are obviously true to anyone with a basic understanding of
> the domain.
So you are unable to actually reference any credible source of information to 
back up your claims then.

> 
> > GLEP55 explicitly states that the EAPI to be recorded in the file
> > extension, while, as this thread has shown, a number of methods can
> > be used to source the EAPI version of the ebuild *without* the need
> > of actually source'ing the ebuild (grep, sed, metacache) all of which
> > are viable solutions to the problem, the problem that is so obvious
> > it doesn't actually have to be defined
> 
> Except that that isn't true. With the current rules, an ebuild has to
> be sourced to get EAPI. And you can't just say "use the metadata
> cache", since the package manager has to know how to generate the
> metadata cache in the first place.
> 
> Please make sure you're familiar with the basics of how metadata works
> before commenting any further.
> 
What has my understanding or lack of understanding of "metadata" have to do 
with my statement that other means exist to determine the EAPI of an ebuild 
before sourcing said ebuild? This is meant to be a discussion about "The 
fallacies of GLEP55" 

Refusal to accept any other possible solution as well as refusal to discuss any 
other solution to the problem, all wrapped up in an awe of supremacy on the 
matter (without ONCE providing details) is not beneficial to Gentoo in finding 
the best solution.

Simple fact is there are many methods available to determine the EAPI of an 
ebuild without having to encode it in the filename (or its extension).
In fact you yourself have mentioned that eclasses change the EAPI
http://article.gmane.org/gmane.linux.gentoo.devel/61255
"But eclasses have tried changing it. This is something people have
done, not some hypothetical." 
So the need to have it actually encoded in the filename is not needed, since 
other method's of actually setting the EAPI exist and work.

Blindly dismissing a solution without actually providing any technical 
information of the problem AS well as why a *proposed* solution isn't the best 
is of no benefit to solving the problem

For instance SheBangs are very useful

FILE:test1.py
#!/usr/bin/python2.5
#-*- coding: utf-8 -*-
def bin(number,count):
return '0b'+"".join([str((number >> y) & 1) for y in range(count-1,-1,-1)])

print 'hello world ',bin(170,8)

FILE:test2.py
#!/usr/bin/python2.6
#-*- coding: utf-8 -*-
print('hello world',bin(170))


executing ./test1  and ./test2 both work WHILE "python2.5 test2.py" fails on 
NameError.
There is no need fo

[gentoo-dev] Re: The fallacies of GLEP55

[Duncan]

Ciaran McCreesh  posted
20090517015039.2fa04...@snowmobile, excerpted below, on  Sun, 17 May 2009
01:50:39 +0100:

> On Sun, 17 May 2009 00:35:45 + (UTC) Duncan <1i5t5.dun...@cox.net>
> wrote:
>> As for ciaranm's argument that you're restricting changes to the
>> version string, say allowing -rc where _rc is now required, one-time
>> restriction of a year or two, yes.  However, if the spec is crafted
>> such that the EAPI must be checked FIRST
> 
> ...then the package manager has to inspect the metadata for every
> version of a package before it can do anything, rather than just
> starting at the best version and working downwards until it finds
> something usable, which is a pretty hefty price to pay.

I'd argue that uncached, certainly, it's a heavy price to pay, tho that's 
so slow as to be hardly workable anyway.

Cached, however, while it's certainly a bit of an increase over the 
current price, I don't believe it inordinately so.  Given that for EAPIs 
the PM doesn't understand it bales anyway, ignoring them, and that EAPI 
is defined as FIRST to be determined, it's an early-out in the can't-deal-
with-it case, and scaled against dependency calculation, grabbing the 
EAPI and establishing a proper ordering shouldn't be /that/ much of a 
cost increase, particularly when the alternative is establishing an 
order, then finding we can't deal with the EAPI of the top of the list 
anyway, so we have to reject it.  It's simply putting EAPI rejection 
earlier in the sequence, dealing with that before establishing order and 
immediately rejecting what we can't handle, rather than establishing 
order first, then checking EAPI and possibly rejecting some versions.

So I believe the cost to be quite reasonably managed, after all.  
Benchmarks would of course be needed to demonstrate that, but I believe 
it worth pursuing.

-- 
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] The fallacies of GLEP55

[Nick Fortino]

Ciaran McCreesh wrote:
> On Sat, 16 May 2009 16:39:40 -0700
> Nick Fortino  wrote:
>   
>> Given the above, it should be clear that any argument which states
>> some future improvement to the ebuild format  will be impossible based
>> upon making the wrong choice between proposal 1 and proposal 2 must be
>> invalid, as they have the same expressive power. Note that allowable
>> algorithms for which the proof works includes caching and version
>> ordering as well as the simple execution of the ebuild.
>> 
>
> Unfortunately, your argument is entirely wrong, as can be illustrated
> by a simple counter-example that you would already know about, had you
> read the GLEP or the thread.
>
> With EAPI in a fixed format, it is impossible to allow extensions to the
> version format in future EAPIs. Even given a fixed format and a constant
> extension, adding foo-1.23-rc1.ebuild will cause breakage, but adding
> foo-1.23-rc1.ebuild-4 will not.
>
> This has already been covered at length, and is explained in the GLEP.
> Why did you disregard this when posting your 'proof'?
>
>   
I didn't intentionally disregard that case, but I see your point. I made
the assumption that package mangers wouldn't try to source ebuilds with
a sourcing EAPI they didn't understand. I concede this is a terrible
assumption, unless such a thing is specified in the PMS itself. It is
still fixed by a single extension change, as opposed to a whole set.
Once this is done, simply state that all package managers should ignore
EAPIs they don't understand (a requirement of GLEP-55 as well).

Your point still does not dispute that specifying the EAPI within the
ebuild and outside the ebuild convey identical information (this is all
I was trying to prove in the first place). For the case you bring up:
If foo-1.23-rc1.ebuild is added, it must not be in any of the currently
existing EAPIs, for if it were, it would be illegal. Thus, a package
manager would open this file, get the sourcing EAPI in an EAPI
independent way, realize it doesn't understand, and abort the sourcing
of that ebuild. Changing the extension once insures current package
managers don't try to do things they aren't capable of (I apologize for
not putting this in my first mailing). Given this change, however, I
still assert the statement of the two schemes have identical expressive
power.

For versioning, it has been pointed out (by you and others) that getting
the latest version would require, under any implementation, opening N
files in case 1, and reading N file names in case 2. I do not dispute
this in any way. Instead, I would like to point out that moving the
argument from features which are possible to support (which I still
contend are essentially identical), to efficiency vs. a perceived
prettiness would be significant progress. Indeed, at this point it would
be possible to make a decision based on reference implementations for
known common use cases, and an executive council decision about whether
timing or extension consistency is more important. If it turns out that
using a solution of type 1 takes minutes to resolve versions, than by
all means, GLEP-55 is by far the best proposed solution. If, instead,
the runtime difference in real use cases is negligible, then the pure
philosophical arguments for using a single extension holds true (in my
opinion).

Nick Fortino

[gentoo-dev] Yet another proposal for ebuild extensions

[Ravi Pinjala]

There's been a lot of noise on this list the past few days about GLEP
55, but precious few solutions actually proposed. Changing the file
extension would certainly be useful for some changes, but the success of
EAPIs >0 which are already in the tree demonstrates that for many
changes, altering the filename is unnecessary. Anything with a .ebuild
extension will have to be parsable by bash according to some set of
rules, for various reasons, so anything more exotic will require a file
extension change. On the other hand, all current ebuilds *do* happen to
parse just fine in bash, so there's no pressing need to change the
extension for current packages.

Instead of changing rules for existing ebuilds, then, why not formalize
some guidelines for non-ebuild-compatible packages in the tree, separate
from EAPIs? Allowing new package formats is the next logical
generalization after considering new and incompatible ebuild formats,
and it would probably be cleaner overall, while giving people the
freedom to experiment with whatever wild ideas they have for packages.

People are going to end up trying out new formats; just look at
kdebuild-1. Rather than trying to put a lid on that sort of thing, and
forcing every Gentoo package to be ebuild-compatible, there should be
some kind of standard for how to treat new package formats, so that
ground rules can be laid out. For instance, the whole thing will fall
apart quickly if there aren't rules about dependencies between packages
of different formats, and there are probably a lot of other issues that
I haven't thought of - all the more reason for standards to be laid out.

--Ravi

[gentoo-dev] rfc: information on localstatedir

[William Hubbs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

All,

I just submitted a patch today to fix an issue with brltty and it was
partially accepted.

The part of it that wasn't accepted is what brings me to this list.

I was told by the brltty developers that localstatedir should be /var.
I noticed, however, that econf passes --localstatedir=/var/lib to the
configure script.  The way around this was to pass the --localstatedir
option to econf.

My question for this list is, what is localstatedir supposed to be?

- -- 
William Hubbs
gentoo accessibility team lead
willi...@gentoo.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkoPYnIACgkQblQW9DDEZTj8LACfffvwtCe8e6zBk/aJKkatgPUR
nbcAoJH6vHTx7wtioxJuKsTBJbiV/qFA
=aDJ+
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: The fallacies of GLEP55

[Ciaran McCreesh]

On Sun, 17 May 2009 00:35:45 + (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:
> As for ciaranm's argument that you're restricting changes to the
> version string, say allowing -rc where _rc is now required, one-time
> restriction of a year or two, yes.  However, if the spec is crafted
> such that the EAPI must be checked FIRST

...then the package manager has to inspect the metadata for every
version of a package before it can do anything, rather than just
starting at the best version and working downwards until it finds
something usable, which is a pretty hefty price to pay.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

[gentoo-dev] Re: The fallacies of GLEP55

[Duncan]

Nick Fortino  posted 4a0f4ebc.5020...@gmail.com,
excerpted below, on  Sat, 16 May 2009 16:39:40 -0700:

> line 5 shall contain the string EAPI="arg"

Given the bash expansion properties associated with double-quotes, that's 
not really going to work as such.  What if "arg" contains $var, where 
$var is set in either line 3 or the environment?  Now a bash parsing 
results in something far different than the literal string.  Now that 
could be simply restricted out, or the more literal single-quote can be 
chosen instead.  That saves a lot of headaches right there.


As for ciaranm's argument that you're restricting changes to the version 
string, say allowing -rc where _rc is now required, one-time restriction 
of a year or two, yes.  However, if the spec is crafted such that the 
EAPI must be checked FIRST, then after the waiting period, changes in 
version-string in the filename should be allowed, because the magic 
string checking (lines 4 and 5 in your example) can then be relied upon 
to be verified FIRST (well, check the extension, ebuild, without checking 
the rest of the filename, THEN check EAPI, which gives rules for the 
rest, including the rest of the filename), setting the parameters for 
further parsing, including of the filename version-string.  That year or 
two one-time wait could be avoided with a single one-time extension 
change instead, if desired.

-- 
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] The fallacies of GLEP55

[Ravi Pinjala]

Nick Fortino wrote:
> Such a transformation is possible, given the restrictions on arg, as
> well as ebuild format.

Isn't this a bit circular? The whole point of wanting to change the
extension is to get rid of exactly these restrictions; if you assume the
restrictions, then the whole thing is kind of pointless. :)

--Ravi

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

On Sat, 16 May 2009 16:39:40 -0700
Nick Fortino  wrote:
> Given the above, it should be clear that any argument which states
> some future improvement to the ebuild format  will be impossible based
> upon making the wrong choice between proposal 1 and proposal 2 must be
> invalid, as they have the same expressive power. Note that allowable
> algorithms for which the proof works includes caching and version
> ordering as well as the simple execution of the ebuild.

Unfortunately, your argument is entirely wrong, as can be illustrated
by a simple counter-example that you would already know about, had you
read the GLEP or the thread.

With EAPI in a fixed format, it is impossible to allow extensions to the
version format in future EAPIs. Even given a fixed format and a constant
extension, adding foo-1.23-rc1.ebuild will cause breakage, but adding
foo-1.23-rc1.ebuild-4 will not.

This has already been covered at length, and is explained in the GLEP.
Why did you disregard this when posting your 'proof'?

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] The fallacies of GLEP55

[Nick Fortino]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ciaran McCreesh wrote:
> On Sat, 16 May 2009 22:39:46 +0530
> Arun Raghavan  wrote:
>  
>> On Sat, 2009-05-16 at 17:59 +0100, Ciaran McCreesh wrote:
>>
 Don't care. Let's fix the problems we have *now* using solutions
 that we can agree upon, rather than try to foist solutions that a
 reasonably large population of developers *don't* like (even after
 extended debate) to solve problems that don't exist yet.

>>> No, let's fix it so we don't have to do the whole thing again in
>>> another year or two.
>>>  
>> I see nothing about the current problem that merits the fooling around
>> with the ebuild extension. I've listened to and considered all the
>> arguments that have been made, and I still stand by my opinion that it
>> an unclean solution (meaning, we don't need to rehash those arguments
>> again here).
>>
>
> You have yet to provide an alternative for fixing the arbitrary and
> pointless version format restrictions that are currently in place.
>
>
>  

It seems to me that putting the EAPI in a fixed place in the file has
nearly identical freedom as specifying the EAPI in the file name, and
therefore the argument is more philosophical than based upon features.

To be concrete, consider two proposals,
1. For an ebuild wishing to be sourced with EAPI != 0, line 4 shall be
blank and line 5 shall contain the string EAPI="arg", where arg is the
desired EAPI.
2. An ebuild wishing to be sourced with EAPI != 0 shall have the
extension .ebuild-EAPIarg, where arg is the desired EAPI.

Throughout, these shall be referred to as ebuilds of type 1 and 2
respectively.

I claim for any format where the concept of line 4 and line 5 are well
defined and identical across EAPIs, and the EAPI string embeddable in
the file name, these two proposals allow identical expressive power.[1][2]

"Proof":
Given a set of ebuilds of type 1 transform to ebuilds of type 2 as
follows: for every ebuild ${A}.ebuild, look for a blank line 4 and
line 5 with EAPI="arg". If found, move the ebuild to
${A}.ebuild-EAPIarg, and remove lines 4 and 5. Otherwise, move the
file to ${A}.ebuild-EAPI0.

Given a set of ebuilds of type 2 transform to ebuilds of type 1 as
follows: for every ebuild ${A}.ebuild-EAPIarg, insert a blank line 4
and put the string EAPI="arg" on line 5. move the ebuild to
${A}.ebuild. For every ebuild ${A}.ebuild, insert a blank line 4, and
EAPI="0" on line 5.

Such a transformation is possible, given the restrictions on arg, as
well as ebuild format.

Given the further restriction that any algorithm using ebuilds must
behave identically with ebuilds of unspecified EAPI as with ebuilds
with specified EAPI="0" [3], it can easily be seen that the two
transformations are inverses of each other, and that every ebuild of
either type can be transformed. Thus, the above must be a one-to-one
and onto mapping between the two formats. The conclusion is any
algorithm which can be run on a set of ebuilds type 1 has a set of
ebuilds with type 2 and an appropriate algorithm for which identical
results will be produced, and vice versa [4].

Given the above, it should be clear that any argument which states
some future improvement to the ebuild format  will be impossible based
upon making the wrong choice between proposal 1 and proposal 2 must be
invalid, as they have the same expressive power. Note that allowable
algorithms for which the proof works includes caching and version
ordering as well as the simple execution of the ebuild.


Nick Fortino

[1] I further state, philosophically, any formats which have differing
(including non-existent) concepts of line 4 and line 5 should have
different extensions. Proposal 2 takes care of this automatically. For
any format, the desired EAPI should be specifiable within the file in
a manner uniquely determined by the extension of the file, so proposal
1 is also capable of achieving this freedom.

[2] The astute reader may notice that the concept of a blank line is
also needed, and that line 5 must be capable of encoding the desired
data in a way specified by only the extension. To avoid clutter, these
details are located here, but are in fact restrictions made on the
ebuild format.

[3] There are no algorithms I know of which violate this for EAPI="0",
and I would hope that there are no EAPI="0" ebuilds which are broken
by putting this specification explicitly in the file. Similarly, I
would hope that anything in proposal 2 with EAPI="0" which works with
the .ebuild extension works with the .ebuild-EAPI0 extension.
Note that one could dream up algorithms violating this (take the MD5
hash, do something based on this which affects the outcome). Doing
such a thing where the difference would be visible to the user would
be silly. It is mostly irrelevant for this argument anyway, as it only
affects EAPI="0", which nobody will debate both schemes can handle.

[4] If this is unclear, consider the following (inefficient)
const

Re: [gentoo-dev] Re: The fallacies of GLEP55

[Ciaran McCreesh]

On Sat, 16 May 2009 21:58:10 + (UTC)
Mark Bateman  wrote:
> "The current way of specifying the EAPI in ebuilds is flawed"
> That is not defining the problem, that is an opening statement.

That is the problem.

> "In order to get the EAPI the package manager needs to source the
> ebuild, which itself needs the EAPI in the first place."
> It then describes "a" mechanism utilising an ebuild
> (source /usr/portage...) to obtain the EAPI from within the ebuild
> (EAPI=...). Using this method the entire content of GLEP55 is
> accurate. 
> 
> However, this is not the only method to determine the EAPI of an
> ebuild that exists and as such the viability of GLEP55 as the best
> solution is brought into question

Yes, it is the only method.

> Where is it defined that the ebuild must be sourced 1st?
> Why does the ebuild have to be sourced 1st?

Such things are obviously true to anyone with a basic understanding of
the domain.

> GLEP55 explicitly states that the EAPI to be recorded in the file
> extension, while, as this thread has shown, a number of methods can
> be used to source the EAPI version of the ebuild *without* the need
> of actually source'ing the ebuild (grep, sed, metacache) all of which
> are viable solutions to the problem, the problem that is so obvious
> it doesn't actually have to be defined

Except that that isn't true. With the current rules, an ebuild has to
be sourced to get EAPI. And you can't just say "use the metadata
cache", since the package manager has to know how to generate the
metadata cache in the first place.

Please make sure you're familiar with the basics of how metadata works
before commenting any further.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

[gentoo-dev] Re: The fallacies of GLEP55

[Mark Bateman]

Patrick Lauer  gentoo.org> writes:

> 
> For quite some time (over a year, actually) we've been discussing the
> mysterious and often misunderstood GLEP55. 
> [http://www.gentoo.org/proj/en/glep/glep-0055.html]
> 
> The proposed solution to a problem that is never refined, in short, is to add
> the EAPI into the ebuild filename "to make things easier". Which is a rather
> unsubstantiated idea that doesn't really add up if you look at it ... and it 
> adds some artifacts that we've been laughing about for a decade because 
> microsoft did the exact same thing (binding the executable-ness of a file to 
> the filename).
> 

The problem isn't GLEP55 (as such), it is a bit more subtle then that and runs 
deeper then just this GLEP.

For starters it is the whole GLEP process
GLEP [Gentoo Linux Enhancement Proposals] is meant as a central place to pull 
*proposals* that provide enhancements to Gentoo.
Some are quite self-apparent (GLEP08)
others are a bit more... lacking (GLEP55)
Why is GLEP55 lacking? because it providing a "solution" to a problem that is 
not actually defined
"The current way of specifying the EAPI in ebuilds is flawed"
That is not defining the problem, that is an opening statement.

"In order to get the EAPI the package manager needs to source the ebuild, which 
itself needs the EAPI in the first place."
It then describes "a" mechanism utilising an ebuild (source /usr/portage...) to 
obtain the EAPI from within the ebuild (EAPI=...). Using this method the entire 
content of GLEP55 is accurate. 

However, this is not the only method to determine the EAPI of an ebuild that 
exists and as such the viability of GLEP55 as the best solution is brought into 
question
Where is it defined that the ebuild must be sourced 1st?
Why does the ebuild have to be sourced 1st?


This then results in ml participants taking this GLEP as the *only* solution 
(to a problem that hasn't actually been defined...) with statements like 
"That's *obviously* completely wrong" 
If something was so obvious this GLEP would have been approved/rejected by now, 
but it hasn't because the problem isn't defined "because it is obvious"

If a problem cannot be describe then the problem is not understood by the one 
writing about the problem.


The GLEP process needs to be refined such that some means of initially raising 
a problem (be it a GLEP itself) that describes the problem in as much detail as 
possible. Once said GLEP has been accepted, ie the problem is acknowledged, 
(sub) GLEP's can be submitted providing possible solutions to the problem.

This way the problems encounted with this particular GLEP, a GLEP that keeps on 
re-surfacing, would be minimised

GLEP55 explicitly states that the EAPI to be recorded in the file extension, 
while, as this thread has shown, a number of methods can be used to source the 
EAPI version of the ebuild *without* the need of actually source'ing the ebuild
(grep, sed, metacache) all of which are viable solutions to the problem, the 
problem that is so obvious it doesn't actually have to be defined


Thing is the package manager *needs* to know the EAPI that the ebuild complies 
to before it can source it to ensure 
1) the correct EAPI-specific eclass is inherited
2) Package manager needs to protect itself from ebuild syntax that earlier 
system packages (eg bash) would fail with 


So please just reject GLEP55, not because its wrong but because it is 
incomplete
reject GLEP55 and have a GLEP62 submitted which defines the problem, then 
request GLEP62-{1,2,3...} be submitted providing possible solutions to the 
problem. GLEP55 can then be submitted as a possible solution. Then 
developers/council can vote on the sub-GLEP's to choose which solution is the 
best technically as well as what is best for the users (dev's and general 
users)


Traceability of issues and solutions is needed, traceability that extends 
beyond mailing-lists and irc logs (discussion mediums which are good for 
instantaneous discussion of issues, but are rubbish for returning to an issue a 
few years down the line, no matter how many logs exist). Report the problem 
better

How clear is it from the stored infomation available whether EAPI's when they 
were 1st conceived and added to portage/paludis/pkgcore was the best solution 
to the problem of expanding on ebuild capability. Or more to the point was how 
it was done partly responsible for the mess we are in now? 

If the problem on ebuild expansion was better documented and defined, maybe 
this GLEP wouldn't even exist, we may have been already using *.ebuild-3 
because it was the best solution

Re: [gentoo-dev] Can we stop wasting time and bandwidth? (was: The fallacies of GLEP55)

[Ciaran McCreesh]

On Sat, 16 May 2009 15:27:59 -0600
Denis Dupeyron  wrote:
> > This is another of those issues where whichever way it's done, some
> > people complain.
> 
> As long as you go by the rules those who complain about you doing so
> are wrong. I've been told you were not the kind who was afraid of
> being right.

I'm also not the sort of person who's going to waste hours and hours
documenting answers to every nonsensical objection that people make up.
Most of the objections being raised to GLEP 55 are in the "not even
wrong" category -- people are claiming GLEP 55 is bad because invisible
green cows are eating the moon.

> So, what do you think about my proposition ?

It's pretty clear that objections and voting aren't even being based
upon what the GLEP says these days, so I don't see any point.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Can we stop wasting time and bandwidth? (was: The fallacies of GLEP55)

[Denis Dupeyron]

On Sat, May 16, 2009 at 3:18 PM, Ciaran McCreesh
 wrote:
> Except that at the last Council meeting, there were complaints that
> objections *had* been included and discussed in the GLEP, and claims
> that including such material made the GLEP less clear.

As unfortunate as it is, council members have the right to forget
about some of the details of some of our rules. And we have the right
to remind them about them.

> This is another of those issues where whichever way it's done, some
> people complain.

As long as you go by the rules those who complain about you doing so
are wrong. I've been told you were not the kind who was afraid of
being right.

So, what do you think about my proposition ?

Denis.

Re: [gentoo-dev] Can we stop wasting time and bandwidth? (was: The fallacies of GLEP55)

[Ciaran McCreesh]

On Sat, 16 May 2009 15:13:50 -0600
Denis Dupeyron  wrote:
> If the author had documented these objections and the answers in the
> glep then it would have made it possible to avoid most of what you
> call the nonsense.

Except that at the last Council meeting, there were complaints that
objections *had* been included and discussed in the GLEP, and claims
that including such material made the GLEP less clear.

This is another of those issues where whichever way it's done, some
people complain.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Can we stop wasting time and bandwidth? (was: The fallacies of GLEP55)

[Denis Dupeyron]

On Sat, May 16, 2009 at 8:19 AM, Ciaran McCreesh
 wrote:
> Because the way Gentoo works, any objection to a proposal, valid or not,
> whether or not it's already been addressed, has to be answered before a
> proposal gets anywhere. Thus, every time people post nonsense about
> GLEP 55, every post has to be answered or the Council goes "there are
> unanswered objection, so we'll postpone it".

As usual you are extrapolating, but you're at least partly right.

If the author had documented these objections and the answers in the
glep then it would have made it possible to avoid most of what you
call the nonsense.  Anything buried on the lists, especially in such
threads as those discussing this glep, can't even remotely be
considered documented or addressed. The answers need to explain
everything, even what seems obvious or stupid, in a way that all devs
can understand. There is an attempt at doing this in the glep but it's
long on asserting and short on explaining, and does not cover it all
by far. As it is today the glep is a good draft but definitely not
voting material, which is certainly one of the reasons why voting it
is taking so long.

Piotr, the author, is currently away and has been mostly inactive for
more than a year now. I just talked to him on irc and reminded him
that as per glep 1 "the GLEP author is responsible for building
consensus within the community and documenting dissenting opinions".
Which he is clearly not doing, at least anymore. Whatever the reasons
of his inactivity, the glep should be currently considered without a
champion and its ownership should be transferred as stipulated in glep
1.

Thus, I'm asking council to transfer the ownership of this glep, as
well as glep 54, and restrain from voting on them until the dissenting
opinions have been properly documented in each of them. Any new
champion will be fine with me, but I'm proposing, if you agree, that
you become the new champion as glep 1 doesn't require the champion to
be a developer. I do not doubt that the practical issues due to you
not being a developer will be worked around.

Denis.

Re: [gentoo-dev] Re: The fallacies of GLEP55

[Denis Dupeyron]

Oops, that was supposed to be sent to him directly. Sorry about that.

Denis.

On Sat, May 16, 2009 at 2:11 PM, Denis Dupeyron  wrote:
> Joe !
>
> How are you doing ? I've been meaning to call you but I've been busy
> as hell due to the move. Do you want to have a beer or lunch sometime
> ?
>
> Denis.
>

Re: [gentoo-dev] Re: The fallacies of GLEP55

[Denis Dupeyron]

Joe !

How are you doing ? I've been meaning to call you but I've been busy
as hell due to the move. Do you want to have a beer or lunch sometime
?

Denis.

Re: [gentoo-dev] Re: The fallacies of GLEP55

[Joe Peterson]

David Leverton wrote:
> For comparson, another alternative that some people have suggested is putting 
> it in a specially formatted comment.  This avoids the issue I mentioned 
> because bash doesn't try to parse those at all, so the only rules are those 
> that specify what format the comment should be in.  On the other hand, this 
> isn't backwards compatible with current package managers.

Actually, I prefer the out-of-band approach, as well.  She-bangs are
pretty standard in Linux/Unix (for example).  But either out-of-band or
restricted in-band solutions are preferable to filename extension hacks.

-Joe

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

On Sun, 17 May 2009 00:42:58 +0530
Arun Raghavan  wrote:
> On Sat, 2009-05-16 at 18:55 +0100, Ciaran McCreesh wrote:
> [...]
> > You have yet to provide an alternative for fixing the arbitrary and
> > pointless version format restrictions that are currently in place.
> 
> Create an EAPI for the required changes, fast track inclusion to a
> stable portage.

Can't do that. The package manager has to barf on unrecognised .ebuild
files.

> If this is not viable, make an unrecognised version string cause the
> same fallback as an unsupported EAPI => ignore the ebuild. Again, fast
> track to stable portage, and not so long after, you're done.

Again, no good. First, it means a year or more wait before doing
anything. Second, it removes a whole level of error checking. Third, it
means a package manager can't know what versions are available for a
package without generating metadata for every potential version.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: [RFC] USE_EXPAND for qemu unified ebuild

[Luca Barbato]

Alexey Shvetsov wrote:
its realy a good idea to make targets for qemu selectable =) since not all 
targets work all time at the same condition.


By tomorrow I'm going to push the use_expand changes and the unified 
qemu ebuild.


--

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

Re: [gentoo-dev] Re: Can we stop wasting time and bandwidth? (was: The fallacies of GLEP55)

[Luca Barbato]

Nirbheek Chauhan wrote:

The statistics are irrelevant. Go ahead and count how many posts have
been made about GLEP55 and 54 since they were introduced.. Now please
compare with how many posts have been made about maintainer-wanted.
Then perhaps you will see what I mean by "useless talk".


You may propose other items for the council, so far we got what got 
proposed w/out rejecting anything, feel free to bring up problems, we 
are trying to let people have voice and avoid proposing stuff ourselves, 
vote on them and so be it.


Please bring the discussion on the council meeting.

lu

--

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

Re: [gentoo-dev] The fallacies of GLEP55

[Arun Raghavan]

On Sat, 2009-05-16 at 18:55 +0100, Ciaran McCreesh wrote:
[...]
> You have yet to provide an alternative for fixing the arbitrary and
> pointless version format restrictions that are currently in place.

Create an EAPI for the required changes, fast track inclusion to a
stable portage.

If this is not viable, make an unrecognised version string cause the
same fallback as an unsupported EAPI => ignore the ebuild. Again, fast
track to stable portage, and not so long after, you're done.

-- Arun


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

On Sat, 16 May 2009 20:38:30 +0200
Robert Buchholz  wrote:
> I like the fact that our versioning rules are a fixed subset of the
> sum of all our upstream's versioning rules. It provides a more
> consistent user experience.
>
> As a user, I know it's always "_rc" and never "-rc". Gentoo
> developers take care of mapping all upstream versions onto an
> easy-to-remember set of ebuild versions.

As a user, you don't need to worry. Since 1-rc1 and 1_rc1 would be
defined as equivalent, as a user you can use either and get the same
results. This is already how things work for existing equivalent but
not stringwise-equal versions.

> Bottom line: I see no gain for me as a developer, and a loss of
> consistency for users.

The only impact upon users is that the package manager will be more
likely to give them accurate output when showing versions.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] The fallacies of GLEP55

[Robert Buchholz]

On Saturday 16 May 2009, Ciaran McCreesh wrote:
> Have a look at every package using a MY_PV style thing. Group those
> into "upstream's doing something dumb" and "upstream's being sensible
> but our arbitrary restrictions on rules means we can't follow what
> they do".

I like the fact that our versioning rules are a fixed subset of the sum 
of all our upstream's versioning rules. It provides a more consistent 
user experience.
As a user, I know it's always "_rc" and never "-rc". Gentoo developers 
take care of mapping all upstream versions onto an easy-to-remember set 
of ebuild versions.

The file extension change makes changing versioning rules possible. From 
a developer PoV, this might relieve me from fiddling with MY_PV. 
However, I have to take care of additional fuzz with file extensions 
(As pointed out by klausman).

Bottom line: I see no gain for me as a developer, and a loss of
consistency for users.


Robert


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] The fallacies of GLEP55

[William Hubbs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, May 16, 2009 at 07:14:00PM +0100, Ciaran McCreesh wrote:
> On Sat, 16 May 2009 13:10:07 -0500
> William Hubbs  wrote:
> > Agreed.  The way I have always usedEAPI is, you set it once at the top
> > of the EBUILD and you are done with it.  As far as I know, there is no
> > reason to change EAPI once it is set, and eclasses shouldn't be
> > changing it.
> 
> But eclasses have tried changing it. This is something people have
> done, not some hypothetical.
 
 I see that as an issue with those eclasses then; they need to be fixed
 so they don't change the EAPI.  They can test for it, but that is all
 they should do.  Maybe that needs to be documented somewhere if it
 isn't already.


- -- 
William Hubbs
gentoo accessibility team lead
willi...@gentoo.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkoPBGAACgkQblQW9DDEZThZ8ACdHK+5d2xjzAONo/IcuVPR3D5j
rTkAoLm4c3o7IVxh2kq3SD8aTUaB4ROb
=NjOq
-END PGP SIGNATURE-

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

On Sat, 16 May 2009 13:10:07 -0500
William Hubbs  wrote:
> Agreed.  The way I have always usedEAPI is, you set it once at the top
> of the EBUILD and you are done with it.  As far as I know, there is no
> reason to change EAPI once it is set, and eclasses shouldn't be
> changing it.

But eclasses have tried changing it. This is something people have
done, not some hypothetical.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] The fallacies of GLEP55

[William Hubbs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, May 16, 2009 at 01:11:34PM +0200, Ben de Groot wrote:
> David Leverton wrote:
> > But the point isn't that we want to be able to do those things.  The point 
> > is 
> > that if the EAPI is in the filename, it's blatantly obvious that it has to 
> > be 
> > static, but adding strange and unintuitive restrictions on which shell 
> > constructs can be used is, well, strange and unintuitive.
> 
> Except that we aren't talking about strange and unintuitive. All we are
> saying is basically documenting current usage: put a line with EAPI=
> near the top. That's very straighforward and intuitive. Plus, it works.

Agreed.  The way I have always usedEAPI is, you set it once at the top
of the EBUILD and you are done with it.  As far as I know, there is no
reason to change EAPI once it is set, and eclasses shouldn't be changing
it.

- -- 
William Hubbs
gentoo accessibility team lead
willi...@gentoo.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkoPAX8ACgkQblQW9DDEZTizJACfarJ8hZh4WQ7GC0kuraqTba9u
FhkAn29jolc1O5D/jMWWA6TJaJcUZtbQ
=529O
-END PGP SIGNATURE-

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

On Sat, 16 May 2009 22:39:46 +0530
Arun Raghavan  wrote:
> On Sat, 2009-05-16 at 17:59 +0100, Ciaran McCreesh wrote:
> > > Don't care. Let's fix the problems we have *now* using solutions
> > > that we can agree upon, rather than try to foist solutions that a
> > > reasonably large population of developers *don't* like (even after
> > > extended debate) to solve problems that don't exist yet.
> > 
> > No, let's fix it so we don't have to do the whole thing again in
> > another year or two.
> 
> I see nothing about the current problem that merits the fooling around
> with the ebuild extension. I've listened to and considered all the
> arguments that have been made, and I still stand by my opinion that it
> an unclean solution (meaning, we don't need to rehash those arguments
> again here).

You have yet to provide an alternative for fixing the arbitrary and
pointless version format restrictions that are currently in place.

> I think it makes far more sense to work towards agreeing on a solution
> rather than restating the same arguments every 6 months and reaching
> the same impasse.

We only have one viable solution.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

On Sat, 16 May 2009 19:13:21 +0200
Tobias Klausmann  wrote:
> > Then you include those in your static list not using patterns that
> > deals with them.
> 
> I'm unable to parse this sentence. 

If you're writing a tool that deals with ebuilds, you should have a
list of EAPIs and their associated file extensions. Any EAPI you don't
explicitly support must be ignored as much as possible.

> > Not a problem. We used .kdebuild-1 rather than .ebuild-kdebuild-1
> > for kdebuild, for example.
> 
> Which makes the whole thing more obscure. Are those templates for
> proper Ebuilds? Or maybe something KDE invented and accidentally
> chose a strange name for? The kdebuild example is of limited use:
> very few people outside the original project ever got in contact
> with it. That does not hold true for good ol' ebuilds. As such,
> the confusiong by the ever-mutation file extension would be much
> broader if we did that to the classic portage tree and overlays.

The kdebuild-1 project was extremely useful in testing out ideas and
driving progress forward. We couldn't have used a regular EAPI number
there for obvious reasons, hence the name.

> > You shouldn't be writing anything that even tries to look at any
> > EAPI you don't support. You should be using a static list of file
> > extensions, not a pattern.
> 
> Not every piece of code dealing with ebuilds does care about EAPI
> /at all/.

But that's not the case, since you don't know anything about EAPIs you
don't recognise.

> And it needn't. There is just no way I can do this with
> your proposal:
> 
>   find /usr/local/portage -iname foobar\*ebuild -print

You should ask your package manager to give you the information you
require.

> And I don't pretend that I know a way to ensure that the change
> will be easy. So I advocate *not* going out of our way to comfort
> that possible Mother of All Changes.

This isn't some hypothetical possible change thing. We already know a
whole bunch of things that need a change, and it's highly likely we'll
discover more later on.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: The fallacies of GLEP55

[David Leverton]

On Saturday 16 May 2009 13:14:23 Duncan wrote:
> I mean, for the longest time, the main (among many) boosting claim seemed
> to be that the speed difference between in-file and in-filename made the
> former prohibitive in practice.

No, performance was never the point of GLEP 55.  People like to talk about it 
because, as we all know, Gentoo is for ricers, but it's not relevant and 
never has been, except to the extent that we don't want to make performance 
worse than it is now.

> The argument was originally made that a simple highly specified EAPI=
> declaration in the file itself was too restrictive of all the ways it
> could be specified now -- until it began to be pointed out every time the
> argument was made that the filename method was very similarly
> restricted.

No, no-one has ever claimed that the restricted EAPI= method is bad because 
they /want/ to be able to set it using weird bash tricks.  The problem is 
that, if it appears as a bash assignment you /can/ set it using weird bash 
tricks, and making the PM's own parsing accept a subset of what can happen 
when the ebuild /is/ eventually sourced is going to make a mess.

> I'd argue no, it's no more unintuitive than any other format definition
> choice.  It's the basic format definition, using the long accepted method
> of "magic values" at a "magic location" to define the format version.
> That's very basic definitional, restricted only to the degree necessary
> for practical application of the definition.  Therefore, it's not
> unintuitive, or at least, certainly no more so than arbitrarily defining
> it to be in the filename instead, because "intuitive" now gets defined by
> the format definition at an extremely basic level, well below the level
> at which all the "intuitive or not" fancy stuff gets addressed.

"The format definition at an extremely basic level" is bash, which has no such 
restrictions.

For comparson, another alternative that some people have suggested is putting 
it in a specially formatted comment.  This avoids the issue I mentioned 
because bash doesn't try to parse those at all, so the only rules are those 
that specify what format the comment should be in.  On the other hand, this 
isn't backwards compatible with current package managers.

Re: [gentoo-dev] The fallacies of GLEP55

[Tobias Klausmann]

Hi! 

On Sat, 16 May 2009, Ciaran McCreesh wrote:
> Tobias Klausmann  wrote:
> > > Why? What's the big deal with .ebuild-? or .eapi-?.eb instead
> > > of .ebuild?
> > 
> > One that you illustrate yourself: what aboud .eapi-11.eb or
> > .ebuild-11?
> 
> Then you include those in your static list not using patterns that
> deals with them.

I'm unable to parse this sentence. 

> >  What if you want to be able to choos EAPI names more
> > freely?
> 
> Not a problem. We used .kdebuild-1 rather than .ebuild-kdebuild-1 for
> kdebuild, for example.

Which makes the whole thing more obscure. Are those templates for
proper Ebuilds? Or maybe something KDE invented and accidentally
chose a strange name for? The kdebuild example is of limited use:
very few people outside the original project ever got in contact
with it. That does not hold true for good ol' ebuilds. As such,
the confusiong by the ever-mutation file extension would be much
broader if we did that to the classic portage tree and overlays.

> You shouldn't be writing anything that even tries to look at any EAPI
> you don't support. You should be using a static list of file
> extensions, not a pattern.

Not every piece of code dealing with ebuilds does care about EAPI
/at all/. And it needn't. There is just no way I can do this with
your proposal:

find /usr/local/portage -iname foobar\*ebuild -print

Or it won't be as easy, at least.

> > There is such a things as too much change too quickly. And even
> > if we take that 2 years number: do *you* know what changes we
> > might need in two years? I suspect not. Neither do I (or just
> > about anybody else). I just think the hoops we have to jump
> > through now to tackle hypothetical problems in two (or ten) years
> > aren't worth it. 
> 
> That's my point -- I don't pretend to know what we'll need in the
> future, so I don't advocate a solution that requires that we do know.

And I don't pretend that I know a way to ensure that the change
will be easy. So I advocate *not* going out of our way to comfort
that possible Mother of All Changes.

Don't get me wrong: I don't want to build format dead-ends into
the package manager design specs, either. But I think the amount
of work and hassle you want to pour into avoiding it outweighs
the benefits, however speculative they may be.

Regards,
Tobias

-- 
Found on a small utility knife in MIT's lab supply:
"Caution.  Blade is sharp.  Keep out of children."

Re: [gentoo-dev] The fallacies of GLEP55

[Arun Raghavan]

On Sat, 2009-05-16 at 17:59 +0100, Ciaran McCreesh wrote:
[...]
> > Don't care. Let's fix the problems we have *now* using solutions that
> > we can agree upon, rather than try to foist solutions that a
> > reasonably large population of developers *don't* like (even after
> > extended debate) to solve problems that don't exist yet.
> 
> No, let's fix it so we don't have to do the whole thing again in
> another year or two.

I see nothing about the current problem that merits the fooling around
with the ebuild extension. I've listened to and considered all the
arguments that have been made, and I still stand by my opinion that it
an unclean solution (meaning, we don't need to rehash those arguments
again here).

Bottom line, we (everyone who has been on this discussion from the
beginning) disagree. Just as we did a year ago. Standing steadfast on
the filename extension just means that all the version format problems
that you're trying to solve are going to stand blocked because of it.

I think it makes far more sense to work towards agreeing on a solution
rather than restating the same arguments every 6 months and reaching the
same impasse.

-- Arun


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

On Sat, 16 May 2009 22:24:04 +0530
Arun Raghavan  wrote:
> On Sat, 2009-05-16 at 17:47 +0100, Ciaran McCreesh wrote:
> > Ok, what are all the things requiring format-break changes that
> > we'll want in the next ten years? Please provide a complete list.
> 
> Don't care. Let's fix the problems we have *now* using solutions that
> we can agree upon, rather than try to foist solutions that a
> reasonably large population of developers *don't* like (even after
> extended debate) to solve problems that don't exist yet.

No, let's fix it so we don't have to do the whole thing again in
another year or two.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

On Sat, 16 May 2009 18:54:41 +0200
Tobias Klausmann  wrote:
> > Why? What's the big deal with .ebuild-? or .eapi-?.eb instead
> > of .ebuild?
> 
> One that you illustrate yourself: what aboud .eapi-11.eb or
> .ebuild-11?

Then you include those in your static list not using patterns that
deals with them.

>  What if you want to be able to choos EAPI names more
> freely?

Not a problem. We used .kdebuild-1 rather than .ebuild-kdebuild-1 for
kdebuild, for example.

> > > My point is this: from experience I suspect having a hard change
> > > once and having easy progress on either side of it is preferable
> > > to having mid-range complications all the time.
> > 
> > .ebuild-? is not complicated.
> 
> Oh, it adds a variable portion to something that's otherwise
> static. 
> globregex
> classic   *.ebuild.*\.ebuild
>   \.ebuild$
> 
> pms-style *.ebuild-*  .*\.ebuild-[0-9]+
>   \.ebuild-[0-9]+$
> 
> The newer sort of extension is much more involved to get *really*
> right in patterns. Globs and regexen are only the two most
> popular examples.

You shouldn't be writing anything that even tries to look at any EAPI
you don't support. You should be using a static list of file
extensions, not a pattern.

> > The only way it'll be "in the next ten years" rather than "in the
> > next two years" is if Gentoo continues its current approach of
> > making changes require every single person to agree...
> 
> There is such a things as too much change too quickly. And even
> if we take that 2 years number: do *you* know what changes we
> might need in two years? I suspect not. Neither do I (or just
> about anybody else). I just think the hoops we have to jump
> through now to tackle hypothetical problems in two (or ten) years
> aren't worth it. 

That's my point -- I don't pretend to know what we'll need in the
future, so I don't advocate a solution that requires that we do know.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] The fallacies of GLEP55

[Tobias Klausmann]

Hi! 

On Sat, 16 May 2009, Ciaran McCreesh wrote:

> On Sat, 16 May 2009 18:31:38 +0200
> Tobias Klausmann  wrote:
> > On Sat, 16 May 2009, Ciaran McCreesh wrote:
> > > > So we're not talking about .ebuild-2 for EAPI=2, .ebuild-3 for
> > > > EAPI=3 etc? That would just be silly and it was the first idea I
> > > > got when I saw the proposal.
> > > 
> > > Yes, yes we are. That's just one change, from a static string to a
> > > pattern for a string.
> > > 
> > > Heck, pretend GLEP 55 says .eapi-X.eb instead if it makes you happy.
> > 
> > It doesn't. I forsee a non-trivial amount of extra work, breakage
> > and pain with a moving extension. And not anywhere near enough
> > benefit in exchange for it.
> 
> Why? What's the big deal with .ebuild-? or .eapi-?.eb instead
> of .ebuild?

One that you illustrate yourself: what aboud .eapi-11.eb or
.ebuild-11?  What if you want to be able to choos EAPI names more
freely?

> > I think wanting incremental updates for version specs is a dream
> > we should abandon.
> 
> It's an easy goal that we can deliver without much work. Ignoring it,
> on the other hand, means holding Gentoo back unnecessarily every time
> we want to change something.

And on the "without much work" we disagree wildly. I think it
creates more trouble than it's worth. Being an opinion, it's up
for change, naturally.

> > My point is this: from experience I suspect having a hard change
> > once and having easy progress on either side of it is preferable
> > to having mid-range complications all the time.
> 
> .ebuild-? is not complicated.

Oh, it adds a variable portion to something that's otherwise
static. 
globregex
classic   *.ebuild.*\.ebuild
  \.ebuild$

pms-style *.ebuild-*  .*\.ebuild-[0-9]+
  \.ebuild-[0-9]+$

The newer sort of extension is much more involved to get *really*
right in patterns. Globs and regexen are only the two most
popular examples.

On top of that, other domains that are involved with ebuilds will
be more complex (and complicated) by a variable file extension.

And it's not just the command line for users. All code that
handles these files (yet probably doesn't even care about their
contents) needs to become more complex. 

For all those who think they are regex wizzes: create a regex
that can tell properly formatted email-addresses from improper
ones. From scratch; heeding all RFCs. And no googling!

> > > Well, I strongly doubt that anyone's already thought of all the
> > > useful changes we might want to make in the future, so I don't
> > > think proposing a solution that assumes that they have is a good
> > > idea.
> > 
> > I think it's a river we should think about once we reach it.
> 
> Why? We know we'll reach it. Pretending we won't just means when we do
> reach it, we'll still be crossing it on foot rather than in a
> helicopter.

Every metaphor only goes so far, so I'll abandon it for now. When
we reach a point where we will need another change, we can make
an informed decision. Now, we can only guess what might need
change. As such, it's very difficult to create a system of easy
updates that cover all possibilities.

> > > Otherwise, in another year or two we'll just be back to "well we
> > > need to change extensions again, but let's just do it as a second
> > > one-off thing".
> > 
> > My experience tells me that with proper preparation of *this*
> > change, that can be pushed past the "in the next ten years" mark.
> > And that is close enough to "indefinitely" for me. 
> 
> The only way it'll be "in the next ten years" rather than "in the next
> two years" is if Gentoo continues its current approach of making
> changes require every single person to agree...

There is such a things as too much change too quickly. And even
if we take that 2 years number: do *you* know what changes we
might need in two years? I suspect not. Neither do I (or just
about anybody else). I just think the hoops we have to jump
through now to tackle hypothetical problems in two (or ten) years
aren't worth it. 




-- 
Found on a small utility knife in MIT's lab supply:
"Caution.  Blade is sharp.  Keep out of children."

Re: [gentoo-dev] The fallacies of GLEP55

[Arun Raghavan]

On Sat, 2009-05-16 at 17:47 +0100, Ciaran McCreesh wrote:
> 
> Ok, what are all the things requiring format-break changes that we'll
> want in the next ten years? Please provide a complete list.

Don't care. Let's fix the problems we have *now* using solutions that we
can agree upon, rather than try to foist solutions that a reasonably
large population of developers *don't* like (even after extended debate)
to solve problems that don't exist yet.

-- Arun


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

On Sat, 16 May 2009 22:14:30 +0530
Arun Raghavan  wrote:
> On Sat, 2009-05-16 at 12:39 -0400, Thomas Anderson wrote:
> > For one, there's the restriction that all *-alpha/*-rc has to be
> > represented _rc/_alpha. I plan on doing more research into perhaps
> > lifting this restriction in a future EAPI, but this would of course
> > require glep 55's solution.
> 
> As Tobias stated, I also prefer coming up with solutions to these
> problems *now*, and fixing them, rather than implementing (IMO) a
> fugly solution to make solving potential problems that we don't know
> exist easier.

Ok, what are all the things requiring format-break changes that we'll
want in the next ten years? Please provide a complete list.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] The fallacies of GLEP55

[Arun Raghavan]

On Sat, 2009-05-16 at 12:39 -0400, Thomas Anderson wrote:
[...]
> For one, there's the restriction that all *-alpha/*-rc has to be
> represented _rc/_alpha. I plan on doing more research into perhaps
> lifting this restriction in a future EAPI, but this would of course
> require glep 55's solution.

As Tobias stated, I also prefer coming up with solutions to these
problems *now*, and fixing them, rather than implementing (IMO) a fugly
solution to make solving potential problems that we don't know exist
easier.

-- Arun


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

On Sat, 16 May 2009 22:05:08 +0530
Arun Raghavan  wrote:
> So from all the debate that's going on, the current major issue seems
> to be being able to support '-scm' as per GLEP-54. What other
> restrictions in the version format are you referring to?

Have a look at every package using a MY_PV style thing. Group those
into "upstream's doing something dumb" and "upstream's being sensible
but our arbitrary restrictions on rules means we can't follow what they
do".

There are an awful lot of things in the second category. There's no
good reason, for example, that _alpha is legal but -alpha is not; both
are common.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] The fallacies of GLEP55

[Thomas Anderson]

On Sat, May 16, 2009 at 10:05:08PM +0530, Arun Raghavan wrote:
> On Sat, 2009-05-16 at 16:49 +0100, Ciaran McCreesh wrote:
> > On Sat, 16 May 2009 17:43:32 +0200
> > Tobias Klausmann  wrote:
> > > > That doesn't let us do version format changes.
> > > 
> > > Or are we talking about the *ebuild* versions? I see that as
> > > different matter. Plus: You could change the version format with
> > > the changed extension. I sure do hope there are no plans on
> > > making those changes as often as new EAPIs.
> > 
> > Yes, those. The current rules include some pointless arbitrary
> > restrictions that are only there for historical reasons and that mean
> > people have to mess with convoluted MY_PV things.
> 
> So from all the debate that's going on, the current major issue seems to
> be being able to support '-scm' as per GLEP-54. What other restrictions
> in the version format are you referring to?
> 
> -- Arun

For one, there's the restriction that all *-alpha/*-rc has to be
represented _rc/_alpha. I plan on doing more research into perhaps
lifting this restriction in a future EAPI, but this would of course
require glep 55's solution.

-- 
-
Thomas Anderson
Gentoo Developer
/
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
-

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

On Sat, 16 May 2009 18:31:38 +0200
Tobias Klausmann  wrote:
> On Sat, 16 May 2009, Ciaran McCreesh wrote:
> > > So we're not talking about .ebuild-2 for EAPI=2, .ebuild-3 for
> > > EAPI=3 etc? That would just be silly and it was the first idea I
> > > got when I saw the proposal.
> > 
> > Yes, yes we are. That's just one change, from a static string to a
> > pattern for a string.
> > 
> > Heck, pretend GLEP 55 says .eapi-X.eb instead if it makes you happy.
> 
> It doesn't. I forsee a non-trivial amount of extra work, breakage
> and pain with a moving extension. And not anywhere near enough
> benefit in exchange for it.

Why? What's the big deal with .ebuild-? or .eapi-?.eb instead
of .ebuild?

> I think wanting incremental updates for version specs is a dream
> we should abandon.

It's an easy goal that we can deliver without much work. Ignoring it,
on the other hand, means holding Gentoo back unnecessarily every time
we want to change something.

> My point is this: from experience I suspect having a hard change
> once and having easy progress on either side of it is preferable
> to having mid-range complications all the time.

.ebuild-? is not complicated.

> > Well, I strongly doubt that anyone's already thought of all the
> > useful changes we might want to make in the future, so I don't
> > think proposing a solution that assumes that they have is a good
> > idea.
> 
> I think it's a river we should think about once we reach it.

Why? We know we'll reach it. Pretending we won't just means when we do
reach it, we'll still be crossing it on foot rather than in a
helicopter.

> > Otherwise, in another year or two we'll just be back to "well we
> > need to change extensions again, but let's just do it as a second
> > one-off thing".
> 
> My experience tells me that with proper preparation of *this*
> change, that can be pushed past the "in the next ten years" mark.
> And that is close enough to "indefinitely" for me. 

The only way it'll be "in the next ten years" rather than "in the next
two years" is if Gentoo continues its current approach of making
changes require every single person to agree...

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] The fallacies of GLEP55

[Arun Raghavan]

On Sat, 2009-05-16 at 16:49 +0100, Ciaran McCreesh wrote:
> On Sat, 16 May 2009 17:43:32 +0200
> Tobias Klausmann  wrote:
> > > That doesn't let us do version format changes.
> > 
> > Or are we talking about the *ebuild* versions? I see that as
> > different matter. Plus: You could change the version format with
> > the changed extension. I sure do hope there are no plans on
> > making those changes as often as new EAPIs.
> 
> Yes, those. The current rules include some pointless arbitrary
> restrictions that are only there for historical reasons and that mean
> people have to mess with convoluted MY_PV things.

So from all the debate that's going on, the current major issue seems to
be being able to support '-scm' as per GLEP-54. What other restrictions
in the version format are you referring to?

-- Arun


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] The fallacies of GLEP55

[Tobias Klausmann]

Hi! 

On Sat, 16 May 2009, Ciaran McCreesh wrote:
> > So we're not talking about .ebuild-2 for EAPI=2, .ebuild-3 for
> > EAPI=3 etc? That would just be silly and it was the first idea I
> > got when I saw the proposal.
> 
> Yes, yes we are. That's just one change, from a static string to a
> pattern for a string.
> 
> Heck, pretend GLEP 55 says .eapi-X.eb instead if it makes you happy.

It doesn't. I forsee a non-trivial amount of extra work, breakage
and pain with a moving extension. And not anywhere near enough
benefit in exchange for it.

> > Aside from that, one idea that came to me recently was to specify
> > per tree what kind of files (version-format-wise, EAPI
> > elsewhere[0]) a PM has to expect. Tree distributors (Gentoo
> > itself, other similar distros, overlays... ) would be Providing
> > that information along a similar route as profiles/repo_name.
> > This would also reduce the amount of mixing and matching version
> > formats (something undesirable, if you ask me). It would also
> > make it easier to take a look at historical (snapshots of)
> > repositories.
> 
> It also means an end to nice incremental updates.

I think wanting incremental updates for version specs is a dream
we should abandon. The ordering issues avoided by doing so would
justify it alone, if you ask me. Yes, that means having a flag
day for every repository. But since I figure the new spec will be
a superset of the old spec, that could be automated.

As for EAPI, I feel we agree that it could live inside the file
itself under this scheme.

My point is this: from experience I suspect having a hard change
once and having easy progress on either side of it is preferable
to having mid-range complications all the time.

> Well, I strongly doubt that anyone's already thought of all the useful
> changes we might want to make in the future, so I don't think proposing
> a solution that assumes that they have is a good idea.

I think it's a river we should think about once we reach it.

> Otherwise, in another year or two we'll just be back to "well we need
> to change extensions again, but let's just do it as a second one-off
> thing".

My experience tells me that with proper preparation of *this*
change, that can be pushed past the "in the next ten years" mark.
And that is close enough to "indefinitely" for me. 

Regards,
Tobias
-- 
Found on a small utility knife in MIT's lab supply:
"Caution.  Blade is sharp.  Keep out of children."

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

On Sat, 16 May 2009 18:15:58 +0200
Tobias Klausmann  wrote:
> On Sat, 16 May 2009, Ciaran McCreesh wrote:
> > Tobias Klausmann  wrote:
> > > > Yes, those. The current rules include some pointless arbitrary
> > > > restrictions that are only there for historical reasons and that
> > > > mean people have to mess with convoluted MY_PV things.
> > > 
> > > Still: a sane spec for those plus a sane spec for inside-the-file
> > > EAPI specs can be done with/during *one* extension change. 
> > 
> > GLEP 55's just one extension change: it moves from .ebuild
> > to .ebuild-EAPI.
> 
> So we're not talking about .ebuild-2 for EAPI=2, .ebuild-3 for
> EAPI=3 etc? That would just be silly and it was the first idea I
> got when I saw the proposal.

Yes, yes we are. That's just one change, from a static string to a
pattern for a string.

Heck, pretend GLEP 55 says .eapi-X.eb instead if it makes you happy.

> Aside from that, one idea that came to me recently was to specify
> per tree what kind of files (version-format-wise, EAPI
> elsewhere[0]) a PM has to expect. Tree distributors (Gentoo
> itself, other similar distros, overlays... ) would be Providing
> that information along a similar route as profiles/repo_name.
> This would also reduce the amount of mixing and matching version
> formats (something undesirable, if you ask me). It would also
> make it easier to take a look at historical (snapshots of)
> repositories.

It also means an end to nice incremental updates.

> [0] I see EAPI specification and version-format spec as separate
> issues.

It's something we can do as an EAPI thing, and by doing so we keep the
smooth upgrade path thing.

> > > Any further features that mandate a change in filename format?
> > > Pile them on. 
> > 
> > There probably will be, and we don't know what they all are yet.
> > Unfortunately we can't see the future.
> 
> I meant further as in "not discussed yet".

Well, I strongly doubt that anyone's already thought of all the useful
changes we might want to make in the future, so I don't think proposing
a solution that assumes that they have is a good idea.

Otherwise, in another year or two we'll just be back to "well we need
to change extensions again, but let's just do it as a second one-off
thing".

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] The fallacies of GLEP55

[Tobias Klausmann]

Hi! 

On Sat, 16 May 2009, Ciaran McCreesh wrote:
> Tobias Klausmann  wrote:
> > > Yes, those. The current rules include some pointless arbitrary
> > > restrictions that are only there for historical reasons and that
> > > mean people have to mess with convoluted MY_PV things.
> > 
> > Still: a sane spec for those plus a sane spec for inside-the-file
> > EAPI specs can be done with/during *one* extension change. 
> 
> GLEP 55's just one extension change: it moves from .ebuild
> to .ebuild-EAPI.

So we're not talking about .ebuild-2 for EAPI=2, .ebuild-3 for
EAPI=3 etc? That would just be silly and it was the first idea I
got when I saw the proposal.

Also, I think there might be better options for the new
extensions (.gbuild?, just a random idea).

Aside from that, one idea that came to me recently was to specify
per tree what kind of files (version-format-wise, EAPI
elsewhere[0]) a PM has to expect. Tree distributors (Gentoo
itself, other similar distros, overlays... ) would be Providing
that information along a similar route as profiles/repo_name.
This would also reduce the amount of mixing and matching version
formats (something undesirable, if you ask me). It would also
make it easier to take a look at historical (snapshots of)
repositories.

[0] I see EAPI specification and version-format spec as separate
issues.

> > Any further features that mandate a change in filename format?
> > Pile them on. 
> 
> There probably will be, and we don't know what they all are yet.
> Unfortunately we can't see the future.

I meant further as in "not discussed yet".

Regards,
Tobias
-- 
Found on a small utility knife in MIT's lab supply:
"Caution.  Blade is sharp.  Keep out of children."

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

On Sat, 16 May 2009 17:55:01 +0200
Tobias Klausmann  wrote:
> > Yes, those. The current rules include some pointless arbitrary
> > restrictions that are only there for historical reasons and that
> > mean people have to mess with convoluted MY_PV things.
> 
> Still: a sane spec for those plus a sane spec for inside-the-file
> EAPI specs can be done with/during *one* extension change. 

GLEP 55's just one extension change: it moves from .ebuild
to .ebuild-EAPI.

> Any further features that mandate a change in filename format?
> Pile them on. 

There probably will be, and we don't know what they all are yet.
Unfortunately we can't see the future.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] The fallacies of GLEP55

[Tobias Klausmann]

Hi! 

On Sat, 16 May 2009, Ciaran McCreesh wrote:

> On Sat, 16 May 2009 17:43:32 +0200
> Tobias Klausmann  wrote:
> > > That doesn't let us do version format changes.
> > 
> > Or are we talking about the *ebuild* versions? I see that as
> > different matter. Plus: You could change the version format with
> > the changed extension. I sure do hope there are no plans on
> > making those changes as often as new EAPIs.
> 
> Yes, those. The current rules include some pointless arbitrary
> restrictions that are only there for historical reasons and that mean
> people have to mess with convoluted MY_PV things.

Still: a sane spec for those plus a sane spec for inside-the-file
EAPI specs can be done with/during *one* extension change. 

Any further features that mandate a change in filename format?
Pile them on. 

Regards,
Tobias

-- 
Found on a small utility knife in MIT's lab supply:
"Caution.  Blade is sharp.  Keep out of children."

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

On Sat, 16 May 2009 17:43:32 +0200
Tobias Klausmann  wrote:
> > That doesn't let us do version format changes.
> 
> Or are we talking about the *ebuild* versions? I see that as
> different matter. Plus: You could change the version format with
> the changed extension. I sure do hope there are no plans on
> making those changes as often as new EAPIs.

Yes, those. The current rules include some pointless arbitrary
restrictions that are only there for historical reasons and that mean
people have to mess with convoluted MY_PV things.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: EAPI Changes

[Petteri Räty]

Duncan wrote:
> Petteri Räty  posted 4a0dd0ed.1070...@gentoo.org,
> excerpted below, on  Fri, 15 May 2009 23:30:37 +0300:
> 
>> Indeed there's no problem switching EAPIs as long as a stable Portage
>> supports the EAPI you are migrating to. Portage was buggy with this when
>> EAPI 2 was introduced but that has since been fixed.
> 
> The case at hand is EAPI-0 > EAPI-1.  I've no opinion there.
> 
> However, just this last week I tracked down and provided a patch for an 
> EAPI-0 > EAPI-2 conversion related bug[1] in an existing previously 
> working ebuild, converted without a bump.  It was and remained ~arch so 
> users should have been prepared to cope, but a bump would have been nice 
> and it would have been a SERIOUS mistake to try to do that as stable.
> 

Well even with EAPI 2 it's quite hard to introduce breakage if you
actually test the changes. If you don't do proper testing, then the only
way to prevent breakage is to kick that developer out, no policy is
going to help. (I am not implying we should start kicking people out for
small mistakes though)

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] The fallacies of GLEP55

[Tobias Klausmann]

Hi! 

On Sat, 16 May 2009, Ciaran McCreesh wrote:
> On Sat, 16 May 2009 17:32:24 +0200
> Tobias Klausmann  wrote:
> > On Sat, 16 May 2009, Ciaran McCreesh wrote:
> > > On Sat, 16 May 2009 11:27:10 +0200
> > > Tobias Klausmann  wrote:
> > > > Change the spec, then.
> > > 
> > > If we change the spec, we can't do anything with the change until
> > > we're absolutely sure that everyone's updated both their ebuilds
> > > and their package manager for it.
> > 
> > The change the extension *once*, and make an EAPI spec at the top
> > of the file for that file format. 
> 
> That doesn't let us do version format changes.

What exactly is _needed_ there? EAPI versions could be arbitrary
strings without \n in them. I see nothing you couldn't get into
that.

Or are we talking about the *ebuild* versions? I see that as
different matter. Plus: You could change the version format with
the changed extension. I sure do hope there are no plans on
making those changes as often as new EAPIs.

Regards,
Tobias

-- 
Found on a small utility knife in MIT's lab supply:
"Caution.  Blade is sharp.  Keep out of children."

Re: [gentoo-dev] Re: The fallacies of GLEP55

[Ciaran McCreesh]

On Sat, 16 May 2009 11:34:14 -0400
Richard Freeman  wrote:
> Ciaran McCreesh wrote:
> > Had we gone with any of the other proposals a year ago, we'd be
> > waiting a year every time a new change came along.
> 
> Only if that change prevented obtaining EAPI from wherever it was 
> placed.

...or if you want version format changes.

> > If the Council were not a fan of GLEP 55, they would have voted
> > against it.
> 
> Why?  If there is no reason to move forward with haste why not just 
> leave it out there and see if somebody comes up with a better idea or 
> see if circumstances change?  If the perception was that there were a 
> pressing need for forward movement on this chances are that somebody 
> would have proposed an alternative GLEP and the council would have
> just approved that instead.

Three out of six Council members considered GLEP 55 to be necessary
enough to vote yes on it the last time it was put to a vote...

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

On Sat, 16 May 2009 17:32:24 +0200
Tobias Klausmann  wrote:
> On Sat, 16 May 2009, Ciaran McCreesh wrote:
> > On Sat, 16 May 2009 11:27:10 +0200
> > Tobias Klausmann  wrote:
> > > Change the spec, then.
> > 
> > If we change the spec, we can't do anything with the change until
> > we're absolutely sure that everyone's updated both their ebuilds
> > and their package manager for it.
> 
> The change the extension *once*, and make an EAPI spec at the top
> of the file for that file format. 

That doesn't let us do version format changes.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: The fallacies of GLEP55

[Richard Freeman]

Ciaran McCreesh wrote:


Had we gone with any of the other proposals a year ago, we'd be waiting
a year every time a new change came along.


Only if that change prevented obtaining EAPI from wherever it was 
placed.  If you want to make the rule "EAPI=foo appears at the start of 
a new line at the top of the ebuild - EAPI is obtained from the first 
such line" then that would handle any situation except where the ebuild 
format can't have EAPI=foo at the start of a line.  Even XML could 
handle that (just put it in tags flanking it on different lines - since 
XML ignores newlines).  Even a binary file format could handle that if 
you just put EAPI= in the header.  The only 
thing it wouldn't handle is dynamically setting the EAPI, but I'm not 
aware of any proposals that do (except for splitting the EAPI into two 
parts - one part defines how to obtain the EAPI the other part does it - 
but that also works with EAPI=foo in the ebuild).




If the Council were not a fan of GLEP 55, they would have voted against
it.



Why?  If there is no reason to move forward with haste why not just 
leave it out there and see if somebody comes up with a better idea or 
see if circumstances change?  If the perception was that there were a 
pressing need for forward movement on this chances are that somebody 
would have proposed an alternative GLEP and the council would have just 
approved that instead.

Re: [gentoo-dev] The fallacies of GLEP55

[Tobias Klausmann]

Hi! 

On Sat, 16 May 2009, Ciaran McCreesh wrote:
> On Sat, 16 May 2009 11:27:10 +0200
> Tobias Klausmann  wrote:
> > Change the spec, then.
> 
> If we change the spec, we can't do anything with the change until we're
> absolutely sure that everyone's updated both their ebuilds and their
> package manager for it.

The change the extension *once*, and make an EAPI spec at the top
of the file for that file format. 

I'd rather have the extension change once, with pain, than with
every EAPI change. My opinion is that reflecting the EAPI in the
file name is a very, very Bad Idea.

> > Actually, I personally would prefer taking it out of the
> > parsed-by-bash part entirely. Add it as a shebang-like line at
> > the top:
> > 
> > #EAPI-1
> > 
> > as the first or second line. Allowing it on the second line
> > allows you to later bolt on a true shebang-line if you should so
> > desire. Only having to look at the first two lines makes finding
> > it out easier (note that I don't call that parsing on purpose).
> 
> Would mean we'd have to change every existing ebuild everywhere.

No, it means we have to change every ebuild of which we claim
that it works that way. Versioned file structures *without*
changing the extension have been done and they have worked.

Yes, there may be pain along the way. But that is true no matter
which route we go.

What people prefer is in no small way tied to the amount of pain
they expect from a given solution. And they're right to do so.

Regards,
Tobias
-- 
Found on a small utility knife in MIT's lab supply:
"Caution.  Blade is sharp.  Keep out of children."

Re: [gentoo-dev] Can we stop wasting time and bandwidth? (was: The fallacies of GLEP55)

[Richard Freeman]

Nirbheek Chauhan wrote:

Let's not blatantly ignore our REAL problems. We can no longer afford
to maintain the status-quo of pedantic masturbatory discussions on the
finer points of ebuild formats. We cannot AFFORD to look the other way
while the distro rots away.



What exactly is your proposal?  Ban discussion of GLEP 55?  I doubt less 
posts on GLEP 55 will mean more developers joining arch teams instead, 
or whatever.


People work on the things they want to work on.  If they want to work on 
EAPIs that is fine by me - that is forward progress.  The solution to 
progress in one area and not another is not to stop the area that is 
moving forward.


Sure, if there were actual resource contention at stake that would make 
sense.  However, if you tell a dev not to work on A but instead to work 
on B the most likely outcomes are that they'll:

1.  Work on A anyway.
2.  Start a separate project to work on A if you actively prevent them 
from doing so.

3.  Work on C, or D, or on nothing at all.

At best they might give B a token effort.  After all, if they wanted to 
work on B they would have done so in the first place.  By all means 
advertise needs in case people aren't aware of them and find them 
interesting, but you can put a gun to people's heads and tell them what 
to do.


If you want more people in the arch team start with the -user mailing 
list and take time to mentor somebody who is interested in maintaining 
packages as a dev.  Or, if you'd rather donate money to a fund to offer 
to pay people to do maintenance.

Re: [gentoo-dev] Re: The fallacies of GLEP55

[Ciaran McCreesh]

On Sat, 16 May 2009 11:15:58 -0400
Richard Freeman  wrote:
> Ciaran McCreesh wrote:
> > You've missed the point. The point is, the EAPI process can't avoid
> > the "huge wait before we can use it" for certain types of change
> > that would be extremely useful. GLEP 55 fixes this limitation, and
> > it's the *only* thing that fixes this limitation.
> > 
> 
> Except that if we had just implemented one of other proposals a year
> ago we probably would be done waiting now, while refusal to accept
> anything other than EAPI-in-filename might have you waiting for this
> ten years from now.

Had we gone with any of the other proposals a year ago, we'd be waiting
a year every time a new change came along.

> Sure, you might disagree with this, but that doesn't change the fact 
> that we are at an impasse and I see no sign of this changing anytime 
> soon - the last council clearly wasn't a big fan of GLEP 55 as it 
> stands, and the current council seems to be going in the same
> direction. I guess you can always wait for the next council election
> and see what 2010 brings.  However, I hope you're not going to do
> that to "speed things up!"

If the Council were not a fan of GLEP 55, they would have voted against
it.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: The fallacies of GLEP55

[Richard Freeman]

Ciaran McCreesh wrote:

You've missed the point. The point is, the EAPI process can't avoid the
"huge wait before we can use it" for certain types of change that
would be extremely useful. GLEP 55 fixes this limitation, and it's the
*only* thing that fixes this limitation.



Except that if we had just implemented one of other proposals a year ago 
we probably would be done waiting now, while refusal to accept anything 
other than EAPI-in-filename might have you waiting for this ten years 
from now.


Sure, you might disagree with this, but that doesn't change the fact 
that we are at an impasse and I see no sign of this changing anytime 
soon - the last council clearly wasn't a big fan of GLEP 55 as it 
stands, and the current council seems to be going in the same direction. 
  I guess you can always wait for the next council election and see 
what 2010 brings.  However, I hope you're not going to do that to "speed 
things up!"

[gentoo-dev] 2.6.29 stable plans

[Daniel Drake]

I'm planning to request the stabling of gentoo-sources-2.6.29 on 23rd 
may, 1 week from now. We have no known regressions in the kernel.


Regressions in external packages in the stable tree are tracked in bug 
#264722. Please fix these asap.


Daniel

Re: [gentoo-dev] Re: The fallacies of GLEP55

[Ciaran McCreesh]

On Sat, 16 May 2009 15:50:39 +0100
Steven J Long  wrote:
> Ciaran McCreesh wrote:
> > On Sat, 16 May 2009 11:27:10 +0200
> > Tobias Klausmann  wrote:
> >> Change the spec, then.
> > 
> > If we change the spec, we can't do anything with the change until
> > we're absolutely sure that everyone's updated both their ebuilds
> > and their package manager for it.
> >
> Isn't that what the EAPI process is for?
> 
> The "support every overlay and old version of portage known to Gentoo"
> is a "straw man" as one hears so much of. GLEP-55 makes explicit
> mention of waiting for 2008.0 to ship, and Gentoo is ultimately only
> responsible for the software it ships, including sunrise.

You've missed the point. The point is, the EAPI process can't avoid the
"huge wait before we can use it" for certain types of change that
would be extremely useful. GLEP 55 fixes this limitation, and it's the
*only* thing that fixes this limitation.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

[gentoo-dev] Re: The fallacies of GLEP55

[Steven J Long]

Ciaran McCreesh wrote:

> On Sat, 16 May 2009 11:27:10 +0200
> Tobias Klausmann  wrote:
>> Change the spec, then.
> 
> If we change the spec, we can't do anything with the change until we're
> absolutely sure that everyone's updated both their ebuilds and their
> package manager for it.
>
Isn't that what the EAPI process is for?

The "support every overlay and old version of portage known to Gentoo"
is a "straw man" as one hears so much of. GLEP-55 makes explicit mention
of waiting for 2008.0 to ship, and Gentoo is ultimately only responsible
for the software it ships, including sunrise.

Since this is Gentoo, ofc, users will be kept in the loop, and upgrade paths
will be provided. It's about the users, or it used to be. (As is the GPL.)

>> Actually, I personally would prefer taking it out of the
>> parsed-by-bash part entirely. Add it as a shebang-like line at
>> the top:
>> 
>> #EAPI-1
>> 
>> as the first or second line. Allowing it on the second line
>> allows you to later bolt on a true shebang-line if you should so
>> desire. Only having to look at the first two lines makes finding
>> it out easier (note that I don't call that parsing on purpose).
>
Restricting (via repoman or equivalent) to first non-comment line
means we can use existing ebuilds with a minor edit, which can be
automated as part of repoman, with a warning if not -q etc, and
makes it easier to find, and to scan for. (I agree, it's not
parsing.)
 
> Would mean we'd have to change every existing ebuild everywhere.
> 
>> I was under the impression that it's illegal to change/set the
>> EAPI after using inherit.
> 
> Nope. It's considered by some to be a QA violation, but EAPI's rules
> are the same as the rules for any other metadata variable.
> 
So refine the spec; that's what the discussion is supposed to lead to,
remember?

-- 
#friendly-coders -- We're friendly but we're not /that/ friendly ;-)

Re: [gentoo-dev] Can we stop wasting time and bandwidth? (was: The fallacies of GLEP55)

[Ciaran McCreesh]

On Sat, 16 May 2009 11:28:57 +0530
Nirbheek Chauhan  wrote:
> Why do we let utterly *useless* discussions eat into our precious
> developer time?
> 
> Why is it that this thread has 500 replies

Because the way Gentoo works, any objection to a proposal, valid or not,
whether or not it's already been addressed, has to be answered before a
proposal gets anywhere. Thus, every time people post nonsense about
GLEP 55, every post has to be answered or the Council goes "there are
unanswered objection, so we'll postpone it".

> but Mart's maintainer-wanted thread has less than 10?

Because most people either don't care or don't see it leading to
anything useful.

> I *do not care* if the ebuild format will not be "properly extensible"
> when the need arises. We'll cross that bridge when we get to it.

People are already using hacks in the tree to get per package eclasses.
This is something that should be in EAPI, but can't be.

> Let's not blatantly ignore our REAL problems. We can no longer afford
> to maintain the status-quo of pedantic masturbatory discussions on the
> finer points of ebuild formats. We cannot AFFORD to look the other way
> while the distro rots away.

Part of the reason the distro is rotting away is that isn't delivering
anything new. I'll remind you that EAPIs 2 and 3 fix several extremely
major user complaints.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: The fallacies of GLEP55

[Ciaran McCreesh]

On Sat, 16 May 2009 12:14:23 + (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:
> I mean, for the longest time, the main (among many) boosting claim
> seemed to be that the speed difference between in-file and
> in-filename made the former prohibitive in practice.  Perhaps the
> benchmarks the council asked for are disproving this.  I don't know
> but I know I sure see a lot less of that claim, call it a deemphasis
> if you will, now, only that the filename method (i.e. glep55) isn't
> slower. 

Uhm. No it hasn't. That is completely and utterly wrong.

The main argument has always been that it's the only solution that
allows the full variety of changes.

The performance thing is a side note on a sub argument that's got
nothing to do with the main point. Unfortunately, since GLEP 55 is
clearly the only answer when you consider the variety of changes
argument, people refuse to talk about it.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] The fallacies of GLEP55

[Ciaran McCreesh]

On Sat, 16 May 2009 11:27:10 +0200
Tobias Klausmann  wrote:
> Change the spec, then.

If we change the spec, we can't do anything with the change until we're
absolutely sure that everyone's updated both their ebuilds and their
package manager for it.

> Actually, I personally would prefer taking it out of the
> parsed-by-bash part entirely. Add it as a shebang-like line at
> the top:
> 
> #EAPI-1
> 
> as the first or second line. Allowing it on the second line
> allows you to later bolt on a true shebang-line if you should so
> desire. Only having to look at the first two lines makes finding
> it out easier (note that I don't call that parsing on purpose).

Would mean we'd have to change every existing ebuild everywhere.

> I was under the impression that it's illegal to change/set the
> EAPI after using inherit.

Nope. It's considered by some to be a QA violation, but EAPI's rules
are the same as the rules for any other metadata variable.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

[gentoo-dev] Re: Can we stop wasting time and bandwidth? (was: The fallacies of GLEP55)

[Duncan]

Nirbheek Chauhan  posted
8b4c83ad0905160454h132e44fboecd75784934fe...@mail.gmail.com, excerpted
below, on  Sat, 16 May 2009 17:24:57 +0530:

> That's the question you should ask Duncan. Not me. I provided statistics
> to highlight and provide dramatic effect.

Wow, the number of follow-ups generated on the net due to not properly 
communicating "dramatic effect" must be...  Wow, over all the 
years of email and usenet, what, 500,000?  No, probably too low.  Maybe 
500 million?  Or is it 500 billion? And (somehow we're now counting all 
of Internet history as a single thread, forgetting the fact that if 
that's what we're doing, we don't have to mention thread at all) that's 
what, at least 500,000 unnecessary messages IN THE SAME THREAD. What a 
waste!  Why are we wasting our time on other stuff with such a big waste 
staring us in the face?  If only people would learn to mark 
drama or sarcasm as such!

But a question, what would /you/ do if someone threw out numbers with no 
hint of dramatic effect indicated that you were losing 90%+ of your 
messages, but with no hint in /your/ messages (quotes of stuff you never 
saw the original of, etc) that such loss was occurring?

My reaction was to question it, post my counts, and wait for some clarity 
to appear in the replies, which it did.

Be that as it may, I apologize that given no indication otherwise, I took 
the literal text as just that, literally intended.  It would have saved 
us both some trouble had I (somehow) recognized the intention.  
There really otta be a tag for that!

Of course, what /really/ makes your point is that it wasn't so obvious 
that I couldn't miss it.  If 500 posts was even plausible, to that single 
thread in the given time... well, I guess that makes your intended point, 
doesn't it?  And pretty dramatically, I might add. =:^)

Don't tell me you schemed all of this to make the point even /more/ 
effectively! =:^)

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

[gentoo-dev] Last rites: gnome-base/libghttp

[Gilles Dartiguelongue]

# Gilles Dartiguelongue  (15 May 2009)
# Masked for removal wrt bug #244128. Old, rotten and
# unused. Removal in 30 days.
gnome-base/libghttp

another one bites the dust.

(resent from my gentoo address)

-- 
Gilles Dartiguelongue 
Gentoo


signature.asc
Description: Ceci est une partie de message numériquement signée

[gentoo-dev] Re: The fallacies of GLEP55

[Duncan]

David Leverton  posted
200905161059.53706.levert...@googlemail.com, excerpted below, on  Sat, 16
May 2009 10:59:53 +0100:

> But the point isn't that we want to be able to do those things.  The
> point is that if the EAPI is in the filename, it's blatantly obvious
> that it has to be static, but adding strange and unintuitive
> restrictions on which shell constructs can be used is, well, strange and
> unintuitive.

Has it really come down to this?

I mean, for the longest time, the main (among many) boosting claim seemed 
to be that the speed difference between in-file and in-filename made the 
former prohibitive in practice.  Perhaps the benchmarks the council asked 
for are disproving this.  I don't know but I know I sure see a lot less 
of that claim, call it a deemphasis if you will, now, only that the 
filename method (i.e. glep55) isn't slower. 

Now, the main argument seems to be that glep55 filename based eapis are 
"more intuitive".  

The argument was originally made that a simple highly specified EAPI= 
declaration in the file itself was too restrictive of all the ways it 
could be specified now -- until it began to be pointed out every time the 
argument was made that the filename method was very similarly 
restricted.  

Now that argument has been debunked and no longer works as it did, so it 
seems the reasons now being presented are what they have left, that the 
filename restriction is "blatantly obvious", while the in-file EAPI= 
restrictions are "unintuitive".

I'd argue no, it's no more unintuitive than any other format definition 
choice.  It's the basic format definition, using the long accepted method 
of "magic values" at a "magic location" to define the format version.  
That's very basic definitional, restricted only to the degree necessary 
for practical application of the definition.  Therefore, it's not 
unintuitive, or at least, certainly no more so than arbitrarily defining 
it to be in the filename instead, because "intuitive" now gets defined by 
the format definition at an extremely basic level, well below the level 
at which all the "intuitive or not" fancy stuff gets addressed.

Regardless, the practical effect is the same, (relatively) severe 
restrictions from the extremely loose definition we have now.  The 
restrictions are even similar.  Thus, it's only an argument over how 
"intuitive" it is, and, well, a stable "base" definition that's 
unchanging is certainly going to look more "intuitive" than say, what 
features are in each EAPI, the much more difficult and "unintuitive" 
thing devs are already trying to track.

Anyway, if it has come down to arguing how intuitive the two opposing 
options may be, that's GOOD news indeed!  It means the important 
questions are, one way or another, getting resolved.  After that, 
ultimately, it's a council judgment call, and we're actually getting 
close!

Unfortunately, "close" is a relative term. =:^(  Realistically?
I'm not sure it's going to resolve by the end of this council's term, but 
provided the elections don't shake things up too badly, it actually looks 
possible to do so reasonably within the /next/ council's term.  We've 
never actually had it (realistically) that close before!

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

Re: [gentoo-dev] Re: Can we stop wasting time and bandwidth? (was: The fallacies of GLEP55)

[AllenJB]

Nirbheek Chauhan wrote:

On Sat, May 16, 2009 at 4:48 PM, Ben de Groot  wrote:

Nirbheek Chauhan wrote:

The statistics are irrelevant.

So why do you bring them up?



That's the question you should ask Duncan. Not me. I provided
statistics to highlight and provide dramatic effect. People who prefer
to discuss them and make it the primary (and only) point of reply
should reconsider their tactics.


Sorry, but what? You post things to a discussion on a mailing list and 
expect people not to discuss them? Then tell those people that THEY are 
the ones who should reconsider their tactics?





This stuff does not need to be resolved, put to rest, approved,
disapproved, or whatever! It needs to be kicked out till we can get
*BASIC* stuff fixed.

I agree, but apparently council thinks it's worth their time.

But I disagree on the maintainer-wanted thread. It's not that important
an issue. We have Sunrise already, so let's try to improve that.



Alright, so you say it's not that important. Then bring things up that
*are* that important. Then we can solve those instead.



While I disagree with the maintainer-wanted project idea itself, the 
fact that it has appeared does mean people are thinking about these 
things and the thread has brought up discussion on what is wrong with 
Gentoo and how it can be fixed. These are good things.


While the original idea may not be implemented, the discussion it has 
brought about will hopefully push things a little further in the right 
direction.


AllenJB

Re: [gentoo-dev] Re: Can we stop wasting time and bandwidth? (was: The fallacies of GLEP55)

[Nirbheek Chauhan]

On Sat, May 16, 2009 at 4:48 PM, Ben de Groot  wrote:
> Nirbheek Chauhan wrote:
>> The statistics are irrelevant.
>
> So why do you bring them up?
>

That's the question you should ask Duncan. Not me. I provided
statistics to highlight and provide dramatic effect. People who prefer
to discuss them and make it the primary (and only) point of reply
should reconsider their tactics.

>> This stuff does not need to be resolved, put to rest, approved,
>> disapproved, or whatever! It needs to be kicked out till we can get
>> *BASIC* stuff fixed.
>
> I agree, but apparently council thinks it's worth their time.
>
> But I disagree on the maintainer-wanted thread. It's not that important
> an issue. We have Sunrise already, so let's try to improve that.
>

Alright, so you say it's not that important. Then bring things up that
*are* that important. Then we can solve those instead.

-- 
~Nirbheek Chauhan

[gentoo-dev] Re: The fallacies of GLEP55

[Duncan]

Tobias Klausmann  posted
20090516092710.ga3...@eric.schwarzvogel.de, excerpted below, on  Sat, 16
May 2009 11:27:10 +0200:

> On Fri, 15 May 2009, Ciaran McCreesh wrote:
 
>> or:
>> 
>> inherit versionator
>> 
>> if version_is_at_least 2 ; then
>> EAPI="2"
>> else
>> EAPI="0"
>> fi
> 
> I was under the impression that it's illegal to change/set the EAPI
> after using inherit.

The short answer, based on my understanding of posts to this point, would 
be that it's illegal for Gentoo (in-tree, council decided), but not 
necessarily for all the overlays and Gentoo based projects out there.

On the one hand, as a result of the above, Gentoo doesn't have to concern 
itself with the others and can decide what's best for the Gentoo tree and 
dev-sponsored overlays presumably targeted at eventual tree inclusion.  
On the other, regardless of what Gentoo decides, PMs wishing widest 
compatibility must be prepared for it anyway.  If I'm not mistaken, 
paludis has the widest deployment footprint both in practice and by goal 
at this point, so naturally, those developing it have broader concerns 
than just Gentoo.

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

Re: [gentoo-dev] Re: Can we stop wasting time and bandwidth? (was: The fallacies of GLEP55)

[Ben de Groot]

Nirbheek Chauhan wrote:
> The statistics are irrelevant.

So why do you bring them up?

> This stuff does not need to be resolved, put to rest, approved,
> disapproved, or whatever! It needs to be kicked out till we can get
> *BASIC* stuff fixed.

I agree, but apparently council thinks it's worth their time.

But I disagree on the maintainer-wanted thread. It's not that important
an issue. We have Sunrise already, so let's try to improve that.

Cheers,
-- 
Ben de Groot
Gentoo Linux developer (qt, media, lxde, desktop-misc)
Gentoo Linux Release Engineering PR liaison
__

Re: [gentoo-dev] The fallacies of GLEP55

[Ben de Groot]

David Leverton wrote:
> But the point isn't that we want to be able to do those things.  The point is 
> that if the EAPI is in the filename, it's blatantly obvious that it has to be 
> static, but adding strange and unintuitive restrictions on which shell 
> constructs can be used is, well, strange and unintuitive.

Except that we aren't talking about strange and unintuitive. All we are
saying is basically documenting current usage: put a line with EAPI=
near the top. That's very straighforward and intuitive. Plus, it works.

Cheers,
-- 
Ben de Groot
Gentoo Linux developer (qt, media, lxde, desktop-misc)
Gentoo Linux Release Engineering PR liaison
__

Re: [gentoo-dev] The fallacies of GLEP55

[David Leverton]

On Saturday 16 May 2009 10:27:51 Marijn Schouten (hkBst) wrote:
> How is it possible to do these things encoded in the filename?

For the export example, it's just a matter of using a different bash syntax 
from what the magic regex expects, which is completely irrelevant if it goes 
in the filename instead.  For the versionator one, you would change the 
extension at the same time that you changed the version, removing the need to 
modify the file contents.

But the point isn't that we want to be able to do those things.  The point is 
that if the EAPI is in the filename, it's blatantly obvious that it has to be 
static, but adding strange and unintuitive restrictions on which shell 
constructs can be used is, well, strange and unintuitive.

Re: [gentoo-dev] libusb-1/libusb-compat landing - testing and DEPEND changes needed

[Robin H. Johnson]

On Thu, May 14, 2009 at 05:06:11PM -0700, Robin H. Johnson wrote:
> libusb-1 is in the tree now. 
> 
> This means that you get to go and test all your apps that use it.
> There's a list further down of all packages and all ebuilds.
I've opened a tracking bug for the migration:
https://bugs.gentoo.org/show_bug.cgi?id=270039

It gives explicit instructions of what to do.

I've also fixed up a number of the mainstream packages that were
reported broken by the migration or I use in some way already.

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85


pgpTNtn7QlS2O.pgp
Description: PGP signature

Re: [gentoo-dev] Re: [RFC] USE_EXPAND for qemu unified ebuild

[Alexey Shvetsov]

On Суббота 16 мая 2009 03:18:09 Luca Barbato wrote:
> Luca Barbato wrote:
> > Duncan wrote:
> >> Namespace pollution? QEMU_USER_TARGETS and QEMU_SOFTMMU_TARGETS, maybe?
> >
> > Right, anyway either one or two vars, anybody has a strong feeling
> > towards one of them or against any of them?
>
> QEMU_SOFTMMU_TARGETS QEMU_USER_TARGETS, that's it.
>
>
> -USE_EXPAND="APACHE2_MODULES APACHE2_MPMS FOO2ZJS_DEVICES MISDN_CARDS
> FRITZCAPI_CARDS FCDSL_CARDS VIDEO_CARDS DVB_CARDS LIRC_DEVICES
> INPUT_DEVICES LINGUAS USERLAND KERNEL ELIBC CROSSCOMPILE_OPTS ALSA_CARDS
> ALSA_PCM_PLUGINS LCD_DEVICES CAMERAS NETBEANS_MODULES"
> +USE_EXPAND="APACHE2_MODULES APACHE2_MPMS FOO2ZJS_DEVICES MISDN_CARDS
> FRITZCAPI_CARDS FCDSL_CARDS VIDEO_CARDS DVB_CARDS LIRC_DEVICES
> INPUT_DEVICES LINGUAS USERLAND KERNEL ELIBC CROSSCOMPILE_OPTS ALSA_CARDS
> ALSA_PCM_PLUGINS LCD_DEVICES CAMERAS NETBEANS_MODULES
> QEMU_SOFTMMU_TARGETS QEMU_USER_TARGETS"
>
>
> alpha - userspace emulation target
> armeb - userspace emulation target
> arm - userspace emulation target
> cris - userspace emulation target
> i386 - userspace emulation target
> m68k - userspace emulation target
> mips64el - userspace emulation target
> mips64 - userspace emulation target
> mipsel - userspace emulation target
> mips - userspace emulation target
> ppc64abi32 - userspace emulation target
> ppc64 - userspace emulation target
> ppc - userspace emulation target
> sh4eb - userspace emulation target
> sh4 - userspace emulation target
> sparc32plus - userspace emulation target
> sparc64 - userspace emulation target
> sparc - userspace emulation target
> x86_64 - userspace emulation target
>
> arm - system emulation target
> cris - system emulation target
> i386 - system emulation target
> m68k - system emulation target
> mips64el - system emulation target
> mips64 - system emulation target
> mipsel - system emulation target
> mips - system emulation target
> ppc64 - system emulation target
> ppc - system emulation target
> sh4eb - system emulation target
> sh4 - system emulation target
> sparc - system emulation target
> x86_64 - system emulation target
> ppcemb - system emulation target
>
> If anybody is against it please tell ^^
>
> lu
its realy a good idea to make targets for qemu selectable =) since not all 
targets work all time at the same condition.
-- 
Alexey 'Alexxy' Shvetsov
Gentoo/KDE
Gentoo/MIPS
Gentoo/Sci
Gentoo Team Ru


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] The fallacies of GLEP55

[Marijn Schouten (hkBst)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ciaran McCreesh wrote:
> On Fri, 15 May 2009 14:43:29 -0500
> William Hubbs  wrote:
>> On Thu, May 14, 2009 at 10:53:37PM +0100, Ciaran McCreesh wrote:
>>> It can't, because it doesn't know the EAPI until it's sourced the
>>> thing using bash. Using things like += in global scope will break
>>> older bash versions to the point that they can't reliably extract
>>> EAPI.
>>  
>> I just figured out a line in bash that will get an EAPI without
>> sourcing the ebuild:
>>
>> eval `grep '^EAPI=' ebuildfile | head -n 1`
>>
>> will set EAPI in the current scope to EAPI in the ebuild, without
>> sourcing it, unless the issue with something like this would be its
>> use of grep and head, but these are both in the system set, so unless
>> you don't want to depend on the system set, I don't know what the
>> objection would be.
> 
> The objection is that your code doesn't work. It's entirely legal to
> do, say:
> 
> export EAPI="1"
> 
> or:
> 
> inherit versionator
> 
> if version_is_at_least 2 ; then
> EAPI="2"
> else
> EAPI="0"
> fi
> 
> Besides, if we were able to do what your code does, we'd just code it
> natively, not use external programs.

How is it possible to do these things encoded in the filename?

Marijn

- --
If you cannot read my mind, then listen to what I say.

Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoOhxcACgkQp/VmCx0OL2wXqACfSkZVqv2hcskm7Yw7vyizeh5r
UnIAn1npT5j6CcN23WE3yG6p8WDZiF9D
=bI9e
-END PGP SIGNATURE-

Re: [gentoo-dev] The fallacies of GLEP55

[Tobias Klausmann]

Hi! 

On Fri, 15 May 2009, Ciaran McCreesh wrote:
> > eval `grep '^EAPI=' ebuildfile | head -n 1`
> > 
> > will set EAPI in the current scope to EAPI in the ebuild, without
> > sourcing it, unless the issue with something like this would be its
> > use of grep and head, but these are both in the system set, so unless
> > you don't want to depend on the system set, I don't know what the
> > objection would be.
> 
> The objection is that your code doesn't work. It's entirely legal to
> do, say:
> 
> export EAPI="1"

Change the spec, then. Or aren't we talking about
writing/changing/clarifying a spec right now? I mean... yes,
ebuilds are actually bash scripts. But I don't see a problem with
using a subset of what's allowed for *this* *specific* line. 

Actually, I personally would prefer taking it out of the
parsed-by-bash part entirely. Add it as a shebang-like line at
the top:

#EAPI-1

as the first or second line. Allowing it on the second line
allows you to later bolt on a true shebang-line if you should so
desire. Only having to look at the first two lines makes finding
it out easier (note that I don't call that parsing on purpose).

> or:
> 
> inherit versionator
> 
> if version_is_at_least 2 ; then
> EAPI="2"
> else
> EAPI="0"
> fi

I was under the impression that it's illegal to change/set the
EAPI after using inherit.

Regards,
Tobias

-- 
Found on a small utility knife in MIT's lab supply:
"Caution.  Blade is sharp.  Keep out of children."

Re: [gentoo-dev] Re: Can we stop wasting time and bandwidth? (was: The fallacies of GLEP55)

[Nirbheek Chauhan]

On Sat, May 16, 2009 at 12:33 PM, Duncan <1i5t5.dun...@cox.net> wrote:
>> Why is it that this thread has 500 replies,
>
> 500?  Try 34 posts in the fallacies of glep55 thread, total, including
> OP, on that thread (not this one, no references header, single post as I
> read this).  But who's counting?  (I wasn't, but just did.)
>
>> but Mart's maintainer-wanted thread has less than 10?
>
> I counted 23, including OP.
>
> That's not such a huge difference, made even less (just eyeballing it,
> perhaps even flipping the lead) if you count only the posts from Gentoo
> devs (yes, that would exclude me, too).
>
> Never-the-less, it's a point worth considering, statistics or not.  But,
> I did see indications the council is acting to come to some conclusion on
> it, which would put it to rest, finally.  They moved on the benchmarks,
> which is really the first physical movement on the thing, and seems to me
> to signal that they are tiring of the debate and want some concrete
> numbers to finally put it to rest, approval or disproval.  We'll see.
>

My god. This just proves that people are not willing to see the oncoming train.

The statistics are irrelevant. Go ahead and count how many posts have
been made about GLEP55 and 54 since they were introduced.. Now please
compare with how many posts have been made about maintainer-wanted.
Then perhaps you will see what I mean by "useless talk".

This stuff does not need to be resolved, put to rest, approved,
disapproved, or whatever! It needs to be kicked out till we can get
*BASIC* stuff fixed.

You don't fuss about the type of faucets in the bathroom when the roof
is falling apart do you?

-- 
~Nirbheek Chauhan

[gentoo-dev] Re: Can we stop wasting time and bandwidth? (was: The fallacies of GLEP55)

[Duncan]

Nirbheek Chauhan  posted
8b4c83ad0905152258i61b0e8ebh869f323519b19...@mail.gmail.com, excerpted
below, on  Sat, 16 May 2009 11:28:57 +0530:

> Why is it that this thread has 500 replies,

500?  Try 34 posts in the fallacies of glep55 thread, total, including 
OP, on that thread (not this one, no references header, single post as I 
read this).  But who's counting?  (I wasn't, but just did.)

> but Mart's maintainer-wanted thread has less than 10?

I counted 23, including OP.

That's not such a huge difference, made even less (just eyeballing it, 
perhaps even flipping the lead) if you count only the posts from Gentoo 
devs (yes, that would exclude me, too).

Never-the-less, it's a point worth considering, statistics or not.  But, 
I did see indications the council is acting to come to some conclusion on 
it, which would put it to rest, finally.  They moved on the benchmarks, 
which is really the first physical movement on the thing, and seems to me 
to signal that they are tiring of the debate and want some concrete 
numbers to finally put it to rest, approval or disproval.  We'll see.

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