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:
> > http://overlays.gentoo.org/proj/java/browser/java-experime
В Втр, 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.
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 Barbat
On Tue, 24 Feb 2009 22:11:47 +
Roy Bamford 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 empty assertion
-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 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*
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?
On Tue, 24 Feb 2009 21:17:57 +
Roy Bamford 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 filename get so long
-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 inform
Ciaran McCreesh wrote:
> On Tue, 24 Feb 2009 09:36:29 -0700
> Joe Peterson 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 enlightened
Alec Warner 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 thre
On Tue, 24 Feb 2009 08:42:44 -0800
Alec Warner wrote:
> On Tue, Feb 24, 2009 at 8:37 AM, Ciaran McCreesh
> wrote:
> > On Tue, 24 Feb 2009 08:33:19 -0800
> > Alec Warner 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
On Tue, 24 Feb 2009 09:45:44 -0700
Joe Peterson 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, we should ad
Ciaran McCreesh wrote:
>> All good points. I cannot believe there exists no other way to solve
>> this technical issue other than resorting to such a non-Unix-like
>> idea. Obviously all of the software packages cited above endeavor to
>> avoid such nastiness.
>
> Then why don't you come up with
On Tue, 24 Feb 2009 09:36:29 -0700
Joe Peterson 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 in ther
On Tue, Feb 24, 2009 at 8:37 AM, Ciaran McCreesh
wrote:
> On Tue, 24 Feb 2009 08:33:19 -0800
> Alec Warner 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
On Tue, 24 Feb 2009 08:33:19 -0800
Alec Warner 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 impact. There's no
Ciaran McCreesh wrote:
> On Tue, 24 Feb 2009 09:24:48 -0700
> Joe Peterson 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
>> foo
On Tue, Feb 24, 2009 at 8:23 AM, Ciaran McCreesh
wrote:
> On Tue, 24 Feb 2009 08:21:25 -0800
> Alec Warner 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;
On Tue, 24 Feb 2009 09:24:48 -0700
Joe Peterson 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 cause great confusi
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 08:21:25 -0800
Alec Warner 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 wouldn't be able to
On Tue, 24 Feb 2009 09:15:59 -0700
Joe Peterson 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 form/design, IMHO.
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
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
On Mon, 23 Feb 2009 20:49:02 -0500
Richard Freeman 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 formatting.
2009/2/24 Ferris McCormick
> On Mon, 2009-02-23 at 22:19 +, Ciaran McCreesh wrote:
> > On Mon, 23 Feb 2009 16:15:25 -0600
> > Ryan Hill 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
On Mon, 2009-02-23 at 22:19 +, Ciaran McCreesh wrote:
> On Mon, 23 Feb 2009 16:15:25 -0600
> Ryan Hill 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 peopl
Ciaran McCreesh wrote:
On Mon, 23 Feb 2009 19:17:19 -0500
Richard Freeman 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 existi
Alistair Bush 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 into a majo
On Mon, 23 Feb 2009 19:17:19 -0500
Richard Freeman 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 package managers,
Ciaran McCreesh wrote:
On Mon, 23 Feb 2009 18:47:07 -0500
Richard Freeman 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 exaggerating a little
On Mon, 23 Feb 2009 18:47:07 -0500
Richard Freeman 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
Description: PGP signature
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 16:15:25 -0600
Ryan Hill wrote:
> On Mon, 23 Feb 2009 20:54:38 +
> Ciaran McCreesh wrote:
>
> > On Mon, 23 Feb 2009 21:51:11 +0100
> > Luca Barbato wrote:
> > > > 2. (with myeclass.eclass containing EAPI=2)
> > > > -
> > > > EAPI=1
> > > > inherit myeclass
> > >
>
On Mon, 23 Feb 2009 16:15:25 -0600
Ryan Hill 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
it, and the spec doe
On Mon, 23 Feb 2009 20:54:38 +
Ciaran McCreesh wrote:
> On Mon, 23 Feb 2009 21:51:11 +0100
> Luca Barbato wrote:
> > > 2. (with myeclass.eclass containing EAPI=2)
> > > -
> > > EAPI=1
> > > inherit myeclass
> >
> > Invalid
>
> QA violation, but legal and a pain in the ass.
I didn't th
On Mon, 23 Feb 2009 21:51:11 +0100
Luca Barbato 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
>
Ryan Hill wrote:
On Mon, 23 Feb 2009 08:43:09 -0700
Steve Dibb 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 even
l
On Mon, 23 Feb 2009 21:30:04 +0200
Petteri Räty 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 would have
Ciaran McCreesh wrote:
> On Mon, 23 Feb 2009 17:48:27 +0100
> Alexis Ballier 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 r
On Mon, 23 Feb 2009 08:43:09 -0700
Steve Dibb 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 even
> > ld-l
On Mon, 23 Feb 2009 11:02:17 -0800
Alec Warner 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 rules. It'
On Mon, Feb 23, 2009 at 7:53 AM, Ciaran McCreesh
wrote:
> On Mon, 23 Feb 2009 08:43:09 -0700
> Steve Dibb 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 an
On Mon, 23 Feb 2009 17:48:27 +0100
Alexis Ballier 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 composable EA
On Mon, 23 Feb 2009 16:19:56 +
Ciaran McCreesh wrote:
> On Mon, 23 Feb 2009 17:13:16 +0100
> Alexis Ballier 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
On Mon, 23 Feb 2009 17:13:16 +0100
Alexis Ballier 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 can be the magic
On Mon, 23 Feb 2009 15:53:20 +
Ciaran McCreesh wrote:
> On Mon, 23 Feb 2009 08:43:09 -0700
> Steve Dibb 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 t
On Mon, 23 Feb 2009 17:06:17 +0100
Peter Alfredsen 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 (and,
obviously, w
On Mon, 23 Feb 2009 08:43:09 -0700
Steve Dibb 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 technically allowed f
On Mon, 23 Feb 2009 08:43:09 -0700
Steve Dibb 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 legal:
In pkg-1.eb
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 15:46:24 +0100
Luca Barbato 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 shipping a load
Ciaran McCreesh wrote:
On Mon, 23 Feb 2009 03:15:03 +0100
Luca Barbato 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 one
On Mon, 23 Feb 2009 09:28:06 -0500
Richard Freeman 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 - keep in mi
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 maj
On Mon, 23 Feb 2009 06:15:25 -0800
Brian Harring 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
> behaviour inclu
On Mon, Feb 23, 2009 at 01:50:10PM +, Ciaran McCreesh wrote:
> On Mon, 23 Feb 2009 04:26:49 -0800
> Brian Harring 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
On Mon, 23 Feb 2009 03:15:03 +0100
Luca Barbato 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 showing an eap
On Mon, 23 Feb 2009 04:26:49 -0800
Brian Harring 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 their feet.
No
Brian Harring 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 stated) by sw
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
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 the
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 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
On Mon, Feb 23, 2009 at 7:02 PM, Tiziano Müller 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 time the
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 princip
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 peopl
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
> > surpri
> 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
68 matches
Mail list logo
