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-22-2007, 12:53 AM
Duncan
 
Default Use EAPI-suffixed ebuilds (.ebuild-EAPI)

Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> posted
20071221135922.3781ecdd@blueyonder.co.uk, excerpted below, on Fri, 21 Dec
2007 13:59:22 +0000:

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

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

But it affects all developers (and power users) in the routine way they
do their job, dealing with ebuilds (or ebuilds plus whatever, if this
GLEP goes thru). As such, it's a "big" change, because it affects how a
lot of people do their routine work.

Yes, that's quibbling over semantics and viewpoint, but it's obvious
/some/ people consider it a big change, big enough for them to make a big
deal about, anyway, which is what matters in terms of discussion and
ultimate acception/rejection of the GLEP.

>> Makes a low-level detail more visible to users.
>
> Users don't see .ebuild files.

"Gentoo users", as often used in the context of this list (from my
observation), do. "Gentoo users" are, as used here, "Gentoo system
sysadmins" by another name. As such, they've always been expected to be
at what the general IT world would consider at minimum "power user",
certainly not the "luser" that's the general IT world's usage of "user".
By definition, "Gentoo users" are expected to be able to RTFM, and
expected to actually /enjoy/ the extra control of being able to mess with
ebuild files and the like. Otherwise, why are they using Gentoo at all,
when it's targeted at that "power user", and there are other
distributions out there directly targeted at the "(l)user" level?

So, "users", as used on this list, *do* see ebuild files, or at minimum,
cannot be reasonably said *not* to see them, since many of them in fact
do see them and make use of them, in overlays and the like.

As for the generally IT world usage of the term, (l)user, that doesn't
come up so often here, because it's not what we deal with. Dealing with
them would be the job of /our/ users -- Gentoo sysadmins by another name.

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

OK, first, a comment on the GLEP itself: I just looked at it again, and
realized it doesn't actually /specify/ the name format in so many words
or in commonly accepted syntax form. One can see what's expected based
on the /examples/, but it's not specified... anywhere that I could see.

So the GLEP needs something like the below (may not be technically
correct, but as an example to be corrected as necessary when added to the
GLEP) syntax specified:

<PF>.ebuild[-<suffix>]

IMO that's the key to beginning to clear up my (I think former)
confusion. Without that clearly stated, I was conflating the two
possible changes, the one given by the GLEP, and the one left unspec-ed,
and thus reserved for the future and/or other non-Gentoo usage,
extensions /other/ than .ebuild[-<suffix>].

Given the conflation, I was then left confused by the GLEP requirement
that the EAPI not be changed from that found in the filename (with the
filename EAPI defaulting to 0 if not given), set against the argument
that EAPI could then at some point be made dynamic, or otherwise less
firmly specified than filename semantics requires. Separating the
concepts, then, clears up the confusion, since the possibility is left
open to change to something /other/ than .ebuild[-<suffix], say fbuild,
in the future (or for other than main Gentoo tree) as necessary, and the
new (fbuild or whatever) format would be free to break all the current
rules associated with .ebuild[-<suffix>] as deemed necessary.

So now I see how you could state they must remain the same (in the glep)
yet allow for dynamically setting them ("post-source") in future non-
ebuild* formats.

Further suggestion for the GLEP, then: In addition to specifying syntax
explicitly, note explicitly as well, that this glep deals with .ebuild*
only, and that one possible mechanism for future incompatible changes
would therefore be to change the extension to something other
than .ebuild*.

This should eliminate an entire class of objections (and simple
confusion), including my main previous one, due to the present less than
clear specification and the confusion it caused.

(/NOW/ I see...! =8^)

--
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@gentoo.org mailing list
 
Old 12-22-2007, 02:19 AM
Luca Barbato
 
Default Use EAPI-suffixed ebuilds (.ebuild-EAPI)

Piotr JaroszyƄski wrote:
> 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.
>

ietf.org Are they ridiculous?


lu

--

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

--
gentoo-dev@gentoo.org mailing list
 
Old 12-22-2007, 02:21 AM
Luca Barbato
 
Default Use EAPI-suffixed ebuilds (.ebuild-EAPI)

Michael Haubenwallner wrote:
> 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}
>

if we are lazy enough we could add this (and add --eapi foo support in
ebuild)

--

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

--
gentoo-dev@gentoo.org mailing list
 
Old 12-22-2007, 02:24 AM
Luca Barbato
 
Default Use EAPI-suffixed ebuilds (.ebuild-EAPI)

Bo Űrsted Andresen wrote:
> On Friday 21 December 2007 03:41:04 Luca Barbato wrote:
>>> * We have to wait a year before we can use it.
>> We have to wait till we got a new release and I hope it isn't 12months.
>
> And then we have to wait till noone use a version of portage that sources the
> ebuild to get the EAPI. Unless we change the file name..
>

Not if we move the rsync path properly so

- older pm sync to a minimal try apt to upgrading portage and nothing else

- newer sync to the full tree now supporting the newer an better and
honey and milk eapi.

Still I think we should just postpone this discussion and get a 2008.0 out.

lu

--

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

--
gentoo-dev@gentoo.org mailing list
 
Old 12-22-2007, 05:35 AM
Steve Long
 
Default Use EAPI-suffixed ebuilds (.ebuild-EAPI)

Duncan wrote:
<snip>
> our users -- Gentoo sysadmins by another name.

THANK YOU! Finally someone said it (and explained it better than I could.)
All our users-- the ones who deal with the glitches that can arise in a
source distro which binary users never see-- have the skill level of an
admin anywhere else.

It might take someone two or three months to get the basics on Gentoo, but
if you can manage a manual install and maintain a Gentoo box, no-one should
be sneering at you (especially as they started out knowing nothing too.)

> Without that clearly stated, I was conflating the two
> possible changes, the one given by the GLEP, and the one left unspec-ed,
> and thus reserved for the future and/or other non-Gentoo usage,
> extensions /other/ than .ebuild[-<suffix>].
>
Interesting: it brings up the possibility of simply using another extension
for files with eapi encoded in the name, and leaving the existing .ebuild
to continue as is.

PMs which don't support versioning would ignore them, since they're
not .ebuild, and existing tools would need the same changes as
with .ebuild-foo; .eapi-foo ?

> Given the conflation, I was then left confused by the GLEP requirement
> that the EAPI not be changed from that found in the filename (with the
> filename EAPI defaulting to 0 if not given), set against the argument
> that EAPI could then at some point be made dynamic, or otherwise less
> firmly specified than filename semantics requires.

But this would have to be based on /some/ sort of eapi suffix in the
filename, or the file would be sourced by current (not future) versions of
portage (the reason for changing the suffix in the first place.) Given that
why not just use the same in the ebuild EAPI="foo" declaration, with the
proviso that it's restricted to only appearing once in the file?

Still seems much cleaner to me. <sarcasm;> Oh yeah, we have to do this *now*
we can't wait 6 months or so, because there are tons of apps that our users
need, which they can't get without ebuilds using an api which can't be
sourced.</sarcasm>

This is supposed to be about the longer-term, not rushing through changes:
it won't exactly take long to get a version of portage that doesn't
automatically source ebuild files: it can just take the first EAPI line it
finds and not source anything it doesn't know about. As ever the maintainer
takes ultimate responsibility for ensuring their ebuild works, and the QA
tool can trivially confirm that there's only one EAPI declaration.
eg, this finds all ebuilds which have more than one SLOT declaration:
find /usr/portage -type f -name '*.ebuild' -exec bash -c 'for f; do
c=$(grep -c "SLOT=" "$f"); ((c>1)) && grep -H SLOT "$f"; done' _ {} +
[all one line]

It's not foolproof (gives false positives eg comments) so I'd use that other
regex for EAPI and put some faith in the maintainers (and the
commit-reviews.)

Oh yeah I forgot, McCreesh thinks they're all idiots[1], so let's just do
what he says. Funny thing is I think the USE-flag metadata thing would have
breezed through as a GLEP; I don't recall one person saying they thought it
was a bad idea.

[1]
http://lab.obsethryl.eu/content/paludis-gentoo-and-ciaran-mccreesh-uncensored


--
gentoo-dev@gentoo.org mailing list
 
Old 12-22-2007, 06:00 AM
Jeroen Roovers
 
Default Use EAPI-suffixed ebuilds (.ebuild-EAPI)

On Fri, 21 Dec 2007 13:34:17 +0100
Piotr JaroszyƄski <peper@gentoo.org> wrote:

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

Yes, for all intents and purposes, assume your readership is in
elementary school. They're certainly not dump, maybe just ignorant, and
whatever you're trying to achieve is coming their way, so you'd better
have them on your side.


Kind regards,
JeR
--
gentoo-dev@gentoo.org mailing list
 
Old 12-22-2007, 06:10 AM
Ciaran McCreesh
 
Default Use EAPI-suffixed ebuilds (.ebuild-EAPI)

On Sat, 22 Dec 2007 01:53:08 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:
> But it affects all developers (and power users) in the routine way
> they do their job, dealing with ebuilds (or ebuilds plus whatever, if
> this GLEP goes thru). As such, it's a "big" change, because it
> affects how a lot of people do their routine work.
>
> Yes, that's quibbling over semantics and viewpoint, but it's obvious
> /some/ people consider it a big change, big enough for them to make a
> big deal about, anyway, which is what matters in terms of discussion
> and ultimate acception/rejection of the GLEP.

Some people consider it a big change because they think they understand
file extensions, and are thus qualified to moan about things.

--
Ciaran McCreesh
 
Old 12-22-2007, 06:12 AM
Ciaran McCreesh
 
Default Use EAPI-suffixed ebuilds (.ebuild-EAPI)

On Sat, 22 Dec 2007 06:35:07 +0000
Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> Oh yeah I forgot, McCreesh thinks they're all idiots[1]

No no. I think some of them are idiots. Get it right.

> Funny thing is I think the USE-flag metadata
> thing would have breezed through as a GLEP; I don't recall one person
> saying they thought it was a bad idea.

But you do recall people saying how it needed extending to be useful.
Yes, it would have breezed through as a GLEP, but it would have had a
half dozen small additions that would have made it a lot more useful.

--
Ciaran McCreesh
 
Old 12-22-2007, 06:13 AM
Ciaran McCreesh
 
Default Use EAPI-suffixed ebuilds (.ebuild-EAPI)

On Sat, 22 Dec 2007 04:19:45 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:
> Piotr JaroszyƄski wrote:
> > 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.
>
> ietf.org Are they ridiculous?

Do you see them explaining what TCP is in great detail in every single
publication that mentions TCP?

--
Ciaran McCreesh
 
Old 12-22-2007, 06:14 AM
Ciaran McCreesh
 
Default Use EAPI-suffixed ebuilds (.ebuild-EAPI)

On Sat, 22 Dec 2007 04:24:06 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:
> Not if we move the rsync path properly so
>
> - older pm sync to a minimal try apt to upgrading portage and nothing
> else
>
> - newer sync to the full tree now supporting the newer an better and
> honey and milk eapi.

...and do it again every three months when a new EAPI comes along.
Great...

--
Ciaran McCreesh
 

Thread Tools




All times are GMT. The time now is 09:18 AM.

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