FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 12-21-2007, 11:34 AM
Piotr Jaroszyński
 
Default Use EAPI-suffixed ebuilds (.ebuild-EAPI)

On Thursday 20 of December 2007 19:29:22 Zhang Le wrote:
> So please make those people understand, so they can comment usefully.

Are we in the elementary school or something? This is really getting
ridiculous.

--
Best Regards,
Piotr Jaroszyński
--
gentoo-dev@gentoo.org mailing list
 
Old 12-21-2007, 12:29 PM
Rmi Cardona
 
Default Use EAPI-suffixed ebuilds (.ebuild-EAPI)

Ciaran McCreesh a crit :
> Developers have to know about EAPIs. It's part of knowing how to write
> ebuilds. There's no way around that -- if you're writing ebuilds, you
> have to know what you are and aren't allowed to do in those ebuilds.

Then please try to keep things simple

The majority of devs don't want to know how portage or paludis work
internally, that's not what interests most of us.

On a somewhat related note : I noticed that among the massive thread,
you have brought up several times the issue of cache generation, saying
that it was a complicated process.

Maybe this process needs to be reworked before the whole EAPI issue can
be resolved?

Cheers,

Rmi
--
gentoo-dev@gentoo.org mailing list
 
Old 12-21-2007, 12:29 PM
Richard Freeman
 
Default Use EAPI-suffixed ebuilds (.ebuild-EAPI)

Ciaran McCreesh wrote:
>
> Ok. What's the EAPI for the following ebuild that's written in an EAPI
> that hasn't been published yet? And how would I extract it?
>
> # Copyright blah blah
>
> import vim-spell using language="en"
>

Counterexample. How do you determine the eapi for the following file,
which uses an EAPI that is yet unpublished - but which specifies that
the EAPI NOT go in the filename: foo-1.2.ebuild

Obviously if you go down one road, and then intentionally change things
to go down another then old stuff won't work. Any package manager that
depends on having the EAPI in the filename won't work if a decision is
later made to remove the EAPI from the filename.

Making a decision to put the EAPI in the filename for all time doesn't
seem any less restricting than making a decision to put EAPI=1 or
EAPI="1" in the ebuild for all time. And the latter is a whole lot less
messy as far as I can see.

So far the only objection I've seen to putting EAPI in the ebuild is
that at some point in the future we might want to do it differently.
Well, that is nice, but the same issue would apply to putting it in the
filename - we could want to change that someday too. And if we put it
in the filename why would we want to put it in a function or whatever
inside the ebuild as well? Wouldn't that just be redundant.

Sure, by not putting it in the filename we restrict ourselves a little
from changing things later. However, if we do put in the filename we
seem to already have a mass of folks who would want to change it RIGHT
NOW.

And if the whole point of this is to allow massive changes to ebuild
format - why not wait until a need for such a change exists before
instituting it. Why not defer this GLEP until it has some benefit and
not just pain associated with it?
 
Old 12-21-2007, 12:31 PM
Richard Freeman
 
Default Use EAPI-suffixed ebuilds (.ebuild-EAPI)

Ciaran McCreesh wrote:
> On Thu, 20 Dec 2007 12:48:31 +0000
> Steve Long <slong@rathaus.eclipse.co.uk> wrote:
>> Point is that your filename format restricts it in exactly the same
>> manner. So let's just stick with the use cases which /that/ supports,
>> which can more easily be supported with the original design and the
>> simple restriction people keep asking for.
>
> Er, the use case is having trivial-as-possible ebuilds for things that
> really are purely eclass managed.
>

How is having a line that states EAPI=foo in the ebuild any less trivial
than putting a -foo at the end of the filename? If anything the latter
is more typing - since the EAPI=foo line would probably be in skel.ebuild...
 
Old 12-21-2007, 12:38 PM
Ciaran McCreesh
 
Default Use EAPI-suffixed ebuilds (.ebuild-EAPI)

On Fri, 21 Dec 2007 14:29:25 +0100
Rmi Cardona <remi@gentoo.org> wrote:
> Ciaran McCreesh a crit :
> > Developers have to know about EAPIs. It's part of knowing how to
> > write ebuilds. There's no way around that -- if you're writing
> > ebuilds, you have to know what you are and aren't allowed to do in
> > those ebuilds.
>
> Then please try to keep things simple

*Using* EAPIs is simple. *Designing* them, not so much.

> The majority of devs don't want to know how portage or paludis work
> internally, that's not what interests most of us.

Which is fine. But then, the majority of devs shouldn't expect to be
able to provide opinions when it comes to the more technical aspects.

> On a somewhat related note : I noticed that among the massive thread,
> you have brought up several times the issue of cache generation,
> saying that it was a complicated process.
>
> Maybe this process needs to be reworked before the whole EAPI issue
> can be resolved?

That's partly what the GLEP is doing. Making it any simpler,
unfortunately, would involve either a huuuuuuge performance hit (we're
talking two orders of magnitude here) or removing metadata from the
ebuilds entirely -- neither of which are viable solutions.

--
Ciaran McCreesh
 
Old 12-21-2007, 12:41 PM
Ciaran McCreesh
 
Default Use EAPI-suffixed ebuilds (.ebuild-EAPI)

On Fri, 21 Dec 2007 08:29:34 -0500
Richard Freeman <rich@thefreemanclan.net> wrote:
> Ciaran McCreesh wrote:
> > Ok. What's the EAPI for the following ebuild that's written in an
> > EAPI that hasn't been published yet? And how would I extract it?
> >
> > # Copyright blah blah
> >
> > import vim-spell using language="en"
> >
>
> Counterexample. How do you determine the eapi for the following file,
> which uses an EAPI that is yet unpublished - but which specifies that
> the EAPI NOT go in the filename: foo-1.2.ebuild

You're back to using a pre-source EAPI to extract the real EAPI then,
which is the way things are currently -- and it means that any EAPI
that specifies what you describe has to be sufficiently close to EAPI 0
that package managers that only understand EAPI 0 will work with it.

> Making a decision to put the EAPI in the filename for all time doesn't
> seem any less restricting than making a decision to put EAPI=1 or
> EAPI="1" in the ebuild for all time. And the latter is a whole lot
> less messy as far as I can see.

It's an awful lot less restrictive.

> So far the only objection I've seen to putting EAPI in the ebuild is
> that at some point in the future we might want to do it differently.
> Well, that is nice, but the same issue would apply to putting it in
> the filename - we could want to change that someday too. And if we
> put it in the filename why would we want to put it in a function or
> whatever inside the ebuild as well? Wouldn't that just be redundant.

If the GLEP is followed, you *can* change the filename to absolutely
anything that isn't either *.ebuild or *.ebuild-(any-previous-eapi), or
various silly things like metadata.xml and files.

> And if the whole point of this is to allow massive changes to ebuild
> format - why not wait until a need for such a change exists before
> instituting it. Why not defer this GLEP until it has some benefit and
> not just pain associated with it?

There is plenty of need, as you would know had you either read the GLEP
or paid attention on this list recently.

--
Ciaran McCreesh
 
Old 12-21-2007, 12:43 PM
Richard Freeman
 
Default Use EAPI-suffixed ebuilds (.ebuild-EAPI)

Ciaran McCreesh wrote:
> Please don't comment any further until you understand how this whole
> thing works.
>

I think this is a bit of an unrealistic expectation. This change
impacts EVERYBODY - devs, users, etc. To expect people not to comment
on it simply because they're not qualified to write a package manager is
a bit naive. Like it or not you do need to obtain some kind of general
agreement before making a change of this magnitude.

Even so - I'm impressed about how civil this discussion has actually
remained.

Feel free to continue to make your points, but a GLEP requires some kind
of census - not just silence after everybody gets tired of hitting
reply. If somebody doesn't know what they're talking about - persuade
them - don't just tell them to be quiet.

I usually like to look at stuff like this in terms of pros and cons. So
here are the pros and cons I can see regarding this change:

PRO:
Very simple to determine the EAPI of an ebuild - regardless of what is
inside
Works with existing PMs
Simple

CON:
Yet another value to be parsed out of an increasingly-complex filename.
Doesn't look pretty
Makes a low-level detail more visible to users.
You can't make a wild change to how EAPIs are specified - since old PMs
will expect it to be in the filename in a particular format.

The other option that seems popular is just continuing with EAPI=1 or
whatever in the file (likely with a restriction on format that makes it
parsable without BASH). I see these pros/cons for this solution:

PRO:
Very simple to determine the EAPI of an ebuild - regardless of what is
inside
Works with existing PMs
Simple
Doesn't add another field to the filename - reducing complexity
Not very visible to users
Looks pretty

CON:
You can't make a wild change to how EAPIs are specified - since old PMs
will expect it to be inside the file in a particular format.

I don't see how the latter is any worse than the former - its main
limitation applies to both methods - just in a different place. I think
you'd get far more consensus to the latter approach. And if for
whatever reason this fails way down the road it could always be moved to
the filename at that time.
 
Old 12-21-2007, 12:59 PM
Ciaran McCreesh
 
Default Use EAPI-suffixed ebuilds (.ebuild-EAPI)

On Fri, 21 Dec 2007 08:43:43 -0500
Richard Freeman <rich@thefreemanclan.net> wrote:
> Ciaran McCreesh wrote:
> > Please don't comment any further until you understand how this whole
> > thing works.
>
> I think this is a bit of an unrealistic expectation. This change
> impacts EVERYBODY - devs, users, etc. To expect people not to comment
> on it simply because they're not qualified to write a package manager
> is a bit naive. Like it or not you do need to obtain some kind of
> general agreement before making a change of this magnitude.

What. It's a small change that's only visible to developers and power
users.

> CON:
> Yet another value to be parsed out of an increasingly-complex
> filename. Doesn't look pretty

It'd only increase complexity in any meaningful way if it were part of
the version part of the ebuild. The version part *is* getting pretty
tricky to parse correctly.

> Makes a low-level detail more visible to users.

Users don't see .ebuild files.

> You can't make a wild change to how EAPIs are specified - since old
> PMs will expect it to be in the filename in a particular format.

You can make entirely arbitrary changes to EAPIs with suffixes,
provided only that you don't use either .ebuild
or .ebuild-(any-existing-eapi).

> The other option that seems popular is just continuing with EAPI=1 or
> whatever in the file (likely with a restriction on format that makes
> it parsable without BASH). I see these pros/cons for this solution:
>
> CON:
> You can't make a wild change to how EAPIs are specified - since old
> PMs will expect it to be inside the file in a particular format.

Bigger con: it means no non-trivial new EAPIs for a year or more.

Another con: EAPI=foo or EAPI="foo" or export EAPI="foo" or what?

> I think you'd get far more consensus to the latter approach.

Yes, but the latter problem doesn't solve anything, so it doesn't
really matter whether or not people like it -- it's utterly pointless.

Counting pros and cons is a bad idea -- a single con can make an idea
completely worthless, whilst ten trivial "it doesn't look quite as
pretty cons" are largely meaningless.

--
Ciaran McCreesh
 
Old 12-21-2007, 01:01 PM
Thomas Anderson
 
Default Use EAPI-suffixed ebuilds (.ebuild-EAPI)

On Friday 21 December 2007 08:43:43 Richard Freeman wrote:
> Ciaran McCreesh wrote:
> > Please don't comment any further until you understand how this whole
> > thing works.
> CON:
> Yet another value to be parsed out of an increasingly-complex filename.
> Doesn't look pretty
Taste is a matter of opinion. I happen to like eapi-1 in the filename so I
know a bit about the ebuild before looking through its contents.
> Makes a low-level detail more visible to users.
> You can't make a wild change to how EAPIs are specified - since old PMs
> will expect it to be in the filename in a particular format.
This isn't a CON, it is actually a PRO because old PMs won't recognize the new
format and everyone will be happy. (something not so easy with the other
solutions.)


--
2.6.23-gentoo-r3
 
Old 12-21-2007, 01:53 PM
Michael Haubenwallner
 
Default Use EAPI-suffixed ebuilds (.ebuild-EAPI)

On Thu, 2007-12-20 at 17:22 +0100, Luca Barbato wrote:

> I'm thinking about having them embedded in the comment as first line as
> something like
>
> #!/usr/bin/env emerge --eapi $foo

OT: It actually works adding this first line and do chmod +x foo.ebuild:

#! /usr/bin/env ebuild

Then you can do: ./foo.ebuild {digest,install,merge,whatever}

/haubi/
--
Michael Haubenwallner
Gentoo on a different level

--
gentoo-dev@gentoo.org mailing list
 

Thread Tools




All times are GMT. The time now is 11:55 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org