В Втр, 24/02/2009 в 16:14 +0200, Serkan Kaba пишет:
lucene-contrib eclass in java-experimental [1] sets EAPI to 1 to use
slot deps. And I think that's a valid usage.
1:
http://overlays.gentoo.org/proj/java/browser/java-experimental/eclass/lucene-contrib.eclass
It's better (the only way...)
On Samstag, 28. Februar 2009, Peter Volkov wrote:
В Втр, 24/02/2009 в 16:14 +0200, Serkan Kaba пишет:
lucene-contrib eclass in java-experimental [1] sets EAPI to 1 to use
slot deps. And I think that's a valid usage.
1:
Alec Warner antarus at gentoo.org writes:
Somewhat ironically, had everyone been less stubborn last year when
discussing this topic we could have embedded the EAPI in line X of the
ebuild in 2008 and be using it now; instead of still discussing it.
I don't expect new novel ideas out of this
Ciaran McCreesh wrote:
On Tue, 24 Feb 2009 09:36:29 -0700
Joe Peterson lava...@gentoo.org wrote:
2) it makes sense to have these in the filename, but not
internal meta-data
For those of us who understand the process, it makes sense to have EAPI
in the filename too.
Which seems to be an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2009.02.24 16:48, Ciaran McCreesh wrote:
[snip]
PN and PV are metadata, same as EAPI.
[snip]
--
Ciaran McCreesh
So we made a mistake with PN and PV and may compound it with EAPI.
How long before we *must* have other pieces of information
On Tue, 24 Feb 2009 21:17:57 +
Roy Bamford neddyseag...@gentoo.org wrote:
PN and PV are metadata, same as EAPI.
So we made a mistake with PN and PV and may compound it with EAPI.
How long before we *must* have other pieces of information in the
filename?
Uh, never.
When will the
Ciaran McCreesh wrote:
On Tue, 24 Feb 2009 21:17:57 +
Except that once we have EAPI in the file extension, we can change
anything we want in arbitrary ways without having to worry about
backwards compatibility, so we won't need silly hacks.
Like the file name structure?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2009.02.24 21:23, Ciaran McCreesh wrote:
On Tue, 24 Feb 2009 21:17:57 +
Roy Bamford neddyseag...@gentoo.org wrote:
PN and PV are metadata, same as EAPI.
So we made a mistake with PN and PV and may compound it with EAPI.
How long
On Tue, 24 Feb 2009 22:11:47 +
Roy Bamford neddyseag...@gentoo.org wrote:
Except that once we have EAPI in the file extension, we can change
anything we want in arbitrary ways without having to worry about
backwards compatibility, so we won't need silly hacks.
Your response amounts to
Ryan Hill wrote:
some other random ideas i've seen tossed around:
- #!/bin/env eapi-parser
- split EAPI into EAPI and some separate counter which would only be
incremented on uncompatible changes to the ebuild format
- change .ebuild to .eb
- waffles (sorry, lunchtime)
Yummy!
--
Luca
2009/2/24 Ferris McCormick fmc...@gentoo.org
On Mon, 2009-02-23 at 22:19 +, Ciaran McCreesh wrote:
On Mon, 23 Feb 2009 16:15:25 -0600
Ryan Hill dirtye...@gentoo.org wrote:
Can we ban eclasses from setting EAPI? Is there any case where it
would be sane?
It's already banned from
On Mon, 23 Feb 2009 20:49:02 -0500
Richard Freeman ri...@gentoo.org wrote:
and it doesn't let you change name or version rules.
Neither does putting the EAPI in the filename as far as I can tell.
Name or versioning rules are things like allowing new suffixes or
altering the restrictions upon
Richard Freeman wrote:
I still don't see why we need to be encoding metadata in filenames.
Correct. GLEP 55 tries to solve a technical implementation issue by
exposing meta data in the filename. Extremely bad form/design, IMHO.
PERL doesn't care what a file extension is, python doesn't care,
Somewhat ironically, had everyone been less stubborn last year when
discussing this topic we could have embedded the EAPI in line X of the
ebuild in 2008 and be using it now; instead of still discussing it.
I don't expect new novel ideas out of this thread. I expect the
council to defer it again
On Tue, 24 Feb 2009 09:15:59 -0700
Joe Peterson lava...@gentoo.org wrote:
Richard Freeman wrote:
I still don't see why we need to be encoding metadata in filenames.
Correct. GLEP 55 tries to solve a technical implementation issue by
exposing meta data in the filename. Extremely bad
On Tue, 24 Feb 2009 08:21:25 -0800
Alec Warner anta...@gentoo.org wrote:
Somewhat ironically, had everyone been less stubborn last year when
discussing this topic we could have embedded the EAPI in line X of the
ebuild in 2008 and be using it now; instead of still discussing it.
...and we
Richard Freeman wrote:
The dynamic linker doesn't need to consult the filename to figure out
how to parse a shared object. It only consults the filename to figure
out which shared object is needed. That is actually analogous to
putting the package name/version in the ebuild filename.
On Tue, 24 Feb 2009 09:24:48 -0700
Joe Peterson lava...@gentoo.org wrote:
Right. Plus, if the linker *did* consult the filename, imagine what
would happen if someone renamed the file (even by accident) and
changed the version? The parser should not be able to be so easily
fooled - could
On Tue, Feb 24, 2009 at 8:23 AM, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
On Tue, 24 Feb 2009 08:21:25 -0800
Alec Warner anta...@gentoo.org wrote:
Somewhat ironically, had everyone been less stubborn last year when
discussing this topic we could have embedded the EAPI in line X of
Ciaran McCreesh wrote:
On Tue, 24 Feb 2009 09:24:48 -0700
Joe Peterson lava...@gentoo.org wrote:
Right. Plus, if the linker *did* consult the filename, imagine what
would happen if someone renamed the file (even by accident) and
changed the version? The parser should not be able to be so
On Tue, 24 Feb 2009 08:33:19 -0800
Alec Warner anta...@gentoo.org wrote:
Hey I never said its a perfect solution; but I'm a fan of the 'it
covers 80%'. Sometimes you can't have your cake and eat it too;
sometimes requirements get dropped.
We can cover 100% with a solution with less of an
On Tue, Feb 24, 2009 at 8:37 AM, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
On Tue, 24 Feb 2009 08:33:19 -0800
Alec Warner anta...@gentoo.org wrote:
Hey I never said its a perfect solution; but I'm a fan of the 'it
covers 80%'. Sometimes you can't have your cake and eat it too;
On Tue, 24 Feb 2009 09:36:29 -0700
Joe Peterson lava...@gentoo.org wrote:
You could use the same absurd argument to say that PN and PV
shouldn't be in the filename...
No...!
They are needed because:
1) versions of the *content*, not the *format* are needed for
uniqueness
So why's PN
On Tue, 24 Feb 2009 09:45:44 -0700
Joe Peterson lava...@gentoo.org wrote:
Then why don't you come up with a viable solution?
I already have - look back at my posts; very similar to Rich0's idea.
No, I said viable.
And I tire of the argument that if one doesn't have a perfect solution
now,
On Tue, 24 Feb 2009 08:42:44 -0800
Alec Warner anta...@gentoo.org wrote:
On Tue, Feb 24, 2009 at 8:37 AM, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
On Tue, 24 Feb 2009 08:33:19 -0800
Alec Warner anta...@gentoo.org wrote:
Hey I never said its a perfect solution; but I'm a fan of
What is proposed in glep-55 seems to aim to solve both issues at the
same time (it isn't stated) by switching file extension every time the
eapi is changed. This is slightly against the principle of the least
surprise and apparently is disliked by enough people to lead the
situation to
On Mon, Feb 23, 2009 at 09:38:06AM +0100, Tiziano M??ller wrote:
What is proposed in glep-55 seems to aim to solve both issues at the
same time (it isn't stated) by switching file extension every time the
eapi is changed. This is slightly against the principle of the least
surprise and
Tiziano Müller wrote:
What is proposed in glep-55 seems to aim to solve both issues at the
same time (it isn't stated) by switching file extension every time the
eapi is changed. This is slightly against the principle of the least
surprise and apparently is disliked by enough people to
Am Montag, den 23.02.2009, 22:25 +1300 schrieb Alistair Bush:
Tiziano Müller wrote:
What is proposed in glep-55 seems to aim to solve both issues at the
same time (it isn't stated) by switching file extension every time the
eapi is changed. This is slightly against the principle of the
On Mon, Feb 23, 2009 at 7:02 PM, Tiziano Müller dev-z...@gentoo.org wrote:
Am Montag, den 23.02.2009, 22:25 +1300 schrieb Alistair Bush:
Tiziano Müller wrote:
What is proposed in glep-55 seems to aim to solve both issues at the
same time (it isn't stated) by switching file extension every
On Mon, Feb 23, 2009 at 07:28:00PM +0900, Douglas Anderson wrote:
On Mon, Feb 23, 2009 at 7:02 PM, Tiziano Müller dev-z...@gentoo.org wrote:
Am Montag, den 23.02.2009, 22:25 +1300 schrieb Alistair Bush:
Tiziano Müller wrote:
What is proposed in glep-55 seems to aim to solve both issues
Tiziano Müller wrote:
What is proposed in glep-55 seems to aim to solve both issues at the
same time (it isn't stated) by switching file extension every time the
eapi is changed. This is slightly against the principle of the least
surprise and apparently is disliked by enough people to lead
On Mon, Feb 23, 2009 at 02:21:33PM +0100, Luca Barbato wrote:
Tiziano M??ller wrote:
What is proposed in glep-55 seems to aim to solve both issues at the same
time (it isn't stated) by switching file extension every time the eapi is
changed. This is slightly against the principle of the
Brian Harring ferri...@gmail.com posted 20090223085232.ga6...@hrair,
excerpted below, on Mon, 23 Feb 2009 00:52:32 -0800:
On Mon, Feb 23, 2009 at 09:38:06AM +0100, Tiziano M??ller wrote:
[quoting...]
What is proposed in glep-55 seems to aim to solve both issues at the
same time (it isn't
On Mon, 23 Feb 2009 04:26:49 -0800
Brian Harring ferri...@gmail.com wrote:
There also is the angle that deploying g55 requires waiting at least
a full stage release (~year, at least by the old standards) to ensure
people aren't screwed by the repository changing formats
(unversioned!) under
On Mon, 23 Feb 2009 03:15:03 +0100
Luca Barbato lu_z...@gentoo.org wrote:
Let's try to start with a common workflow for the user:
- an user with an ancient version of portage syncs
- it requires a package
- it looks at the cache ($portdir/metadata/cache/)
- picks the best entry from the ones
On Mon, Feb 23, 2009 at 01:50:10PM +, Ciaran McCreesh wrote:
On Mon, 23 Feb 2009 04:26:49 -0800
Brian Harring ferri...@gmail.com wrote:
There also is the angle that deploying g55 requires waiting at least
a full stage release (~year, at least by the old standards) to ensure
people
On Mon, 23 Feb 2009 06:15:25 -0800
Brian Harring ferri...@gmail.com wrote:
No it doesn't. It's transparent to users using an older package
manager.
Would be useful if someone pulled older portage versions and checked
exactly what they do in this case- explode, behave, etc (manifest
Douglas Anderson wrote:
No one wants to be working with ebuild-29 or something like that in a
few years and trying to figure out which feature came in which EAPI.
Instead of bumping EAPI for each little change, save them up and bump
no more than once a year or less, each bump bringing in some
On Mon, 23 Feb 2009 09:28:06 -0500
Richard Freeman ri...@gentoo.org wrote:
I got the impression that if anything there is a desire to allow
EAPIs to change more offen, and not less. And these changes could
become more dramatic.
But we're still only talking maybe three new EAPIs a year.
Also
Ciaran McCreesh wrote:
On Mon, 23 Feb 2009 03:15:03 +0100
Luca Barbato lu_z...@gentoo.org wrote:
Let's try to start with a common workflow for the user:
- an user with an ancient version of portage syncs
- it requires a package
- it looks at the cache ($portdir/metadata/cache/)
- picks the best
On Mon, 23 Feb 2009 15:46:24 +0100
Luca Barbato lu_z...@gentoo.org wrote:
Apparently we do not have any issue...
...assuming the metadata cache is valid. That isn't always the case.
When it isn't?
Every now and again (probably after someone changes eutils...), rsync
mirrors end up
Richard Freeman wrote:
I still don't see why we need to be encoding metadata in filenames. PERL
doesn't care what a file extension is, python doesn't care, bzip2
doesn't care, tar doesn't care, gzip doesn't care, and even ld-linux.so
doesn't care. I'm sure that in at least some of these cases
On Mon, 23 Feb 2009 08:43:09 -0700
Steve Dibb bean...@gentoo.org wrote:
Plus, I don't really grasp the whole we have to source the whole
ebuild to know the EAPI version argument. It's one variable, in one
line. Can't a simple parser get that and go from there?
Not true. This is entirely
On Mon, 23 Feb 2009 08:43:09 -0700
Steve Dibb bean...@gentoo.org wrote:
Plus, I don't really grasp the whole we have to source the whole
ebuild to know the EAPI version argument. It's one variable, in one
line. Can't a simple parser get that and go from there?
The problem is that its
On Mon, 23 Feb 2009 17:06:17 +0100
Peter Alfredsen loki_...@gentoo.org wrote:
To be honest I see no good reason for allowing manipulation of it, but
I'm sure other people will tell me why adding this requirement at this
point is wrong
There's not really a good reason to allow manipulating it
On Mon, 23 Feb 2009 15:53:20 +
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
On Mon, 23 Feb 2009 08:43:09 -0700
Steve Dibb bean...@gentoo.org wrote:
Plus, I don't really grasp the whole we have to source the whole
ebuild to know the EAPI version argument. It's one variable, in
On Mon, 23 Feb 2009 17:13:16 +0100
Alexis Ballier aball...@gentoo.org wrote:
Which begs the question: is it really worth allowing it?
If we only allow constant assignments (which is an implicit
restriction in the file extension version) then this can be parsed
easily with grep/tr/awk/etc and
On Mon, 23 Feb 2009 16:19:56 +
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
On Mon, 23 Feb 2009 17:13:16 +0100
Alexis Ballier aball...@gentoo.org wrote:
Which begs the question: is it really worth allowing it?
If we only allow constant assignments (which is an implicit
On Mon, 23 Feb 2009 17:48:27 +0100
Alexis Ballier aball...@gentoo.org wrote:
...and then we have to do the whole thing again every time something
new crops up.
Please give an example because I fail to see how.
New version suffix rules. New bash versions. New package naming rules.
Partially
On Mon, Feb 23, 2009 at 7:53 AM, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
On Mon, 23 Feb 2009 08:43:09 -0700
Steve Dibb bean...@gentoo.org wrote:
Plus, I don't really grasp the whole we have to source the whole
ebuild to know the EAPI version argument. It's one variable, in one
On Mon, 23 Feb 2009 11:02:17 -0800
Alec Warner anta...@gentoo.org wrote:
In foo.eclass:
EAPI=3
This is not legal, the devmanual[1] explicitly states that it is not
legal to set EAPI in an eclass.
That's purely a QA thing, and it only applies to repositories that
follow Gentoo's QA
On Mon, 23 Feb 2009 08:43:09 -0700
Steve Dibb bean...@gentoo.org wrote:
Richard Freeman wrote:
I still don't see why we need to be encoding metadata in filenames.
PERL doesn't care what a file extension is, python doesn't care,
bzip2 doesn't care, tar doesn't care, gzip doesn't care, and
Ciaran McCreesh wrote:
On Mon, 23 Feb 2009 17:48:27 +0100
Alexis Ballier aball...@gentoo.org wrote:
...and then we have to do the whole thing again every time something
new crops up.
Please give an example because I fail to see how.
New version suffix rules. New bash versions. New package
On Mon, 23 Feb 2009 21:30:04 +0200
Petteri Räty betelge...@gentoo.org wrote:
And we'd be starting on the next batch of oh, we need to wait
another year. Had GLEP 55's necessity been accepted a year ago,
we'd have a whole bunch of requested features implemented by now.
I doubt Portage
Ryan Hill wrote:
On Mon, 23 Feb 2009 08:43:09 -0700
Steve Dibb bean...@gentoo.org wrote:
Richard Freeman wrote:
I still don't see why we need to be encoding metadata in filenames.
PERL doesn't care what a file extension is, python doesn't care,
bzip2 doesn't care, tar doesn't care, gzip
On Mon, 23 Feb 2009 21:51:11 +0100
Luca Barbato lu_z...@gentoo.org wrote:
2. (with myeclass.eclass containing EAPI=2)
-
EAPI=1
inherit myeclass
Invalid
QA violation, but legal and a pain in the ass.
3. (with myeclass.eclass containing EAPI=2)
-
EAPI=5
inherit myeclass
On Mon, 23 Feb 2009 20:54:38 +
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
On Mon, 23 Feb 2009 21:51:11 +0100
Luca Barbato lu_z...@gentoo.org wrote:
2. (with myeclass.eclass containing EAPI=2)
-
EAPI=1
inherit myeclass
Invalid
QA violation, but legal and a
On Mon, 23 Feb 2009 16:15:25 -0600
Ryan Hill dirtye...@gentoo.org wrote:
Can we ban eclasses from setting EAPI? Is there any case where it
would be sane?
It's already banned from a QA perspective, but from a package manager
perspective people have done it in the past and possibly still do do
On Mon, 23 Feb 2009 16:15:25 -0600
Ryan Hill dirtye...@gentoo.org wrote:
On Mon, 23 Feb 2009 20:54:38 +
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
On Mon, 23 Feb 2009 21:51:11 +0100
Luca Barbato lu_z...@gentoo.org wrote:
2. (with myeclass.eclass containing EAPI=2)
Ryan Hill wrote:
Richard Freeman wrote:
I'm
actually hard pressed to think of any unix-based software that uses
the filename to store a mandatory file format versioning specifier
of some kind.
$ ls /usr/lib
I was referring to a file FORMAT versioning scheme - not a file CONTENT
versioning
On Mon, 23 Feb 2009 18:47:07 -0500
Richard Freeman ri...@gentoo.org wrote:
It seems like we could be up to ebuild-kde4-3.2 in six months.
Why on earth do people think that? Of all the crazy being thrown
around, this is the only one wearing a tutu.
--
Ciaran McCreesh
signature.asc
Ciaran McCreesh wrote:
On Mon, 23 Feb 2009 18:47:07 -0500
Richard Freeman ri...@gentoo.org wrote:
It seems like we could be up to ebuild-kde4-3.2 in six months.
Why on earth do people think that? Of all the crazy being thrown
around, this is the only one wearing a tutu.
I suppose I'm
On Mon, 23 Feb 2009 19:17:19 -0500
Richard Freeman ri...@gentoo.org wrote:
It just seems like it isn't the best solution. You can get the same
effect by just sticking something in a comment line a few lines into
the ebuild in a fixed position.
No you can't. It doesn't work with existing
Alistair Bush ali_b...@gentoo.org wrote:
Tiziano Müller wrote:
Instead of switching file extension every time the eapi is changed
you could also increment it only when a new EAPI breaks sourcing
the ebuild compared to the requirements of the prior EAPI.
(This way you'd in fact split EAPI
Ciaran McCreesh wrote:
On Mon, 23 Feb 2009 19:17:19 -0500
Richard Freeman ri...@gentoo.org wrote:
It just seems like it isn't the best solution. You can get the same
effect by just sticking something in a comment line a few lines into
the ebuild in a fixed position.
No you can't. It doesn't
66 matches
Mail list logo
