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, 02:31 PM
Bo Ørsted Andresen
Default Use EAPI-suffixed ebuilds (.ebuild-EAPI)

On Friday 21 December 2007 05:25:00 Zhang Le wrote:
> The question is really simple.
> Whether we should have two different place to define EAPI?

We need two places because it wasn't implemented properly in the first place
and we want to retain backwards compatibility for people who use old versions
of portage. The whole point is to keep a sane upgrade path available
indefinitely for people with old versions of portage.

> Proponents are trying to prove that we should at least need it be in file
> name.

We need the file name to change because otherwise old versions of portage will
try to source the ebuild when the EAPI is unknown. This either blocks new
useful features that will make old versions of portage fail to source them or
results in more bug reports with zillions of dupes (like the bugs in [1])
because people with ancient versions of portage feel the need to report bug
reports when portage fails after a sync.

At the very least it means waiting for a year between a release with a version
of portage that supports this and an EAPI that takes advantage of it. So now
that leaves the question whether we want to change the file name once and
hope that we won't need to do it again or whether we want to use the
technically more flexible way where the file name changes whenever a new EAPI
gets agreed upon.

Or alternatively whether we want to limit ourselves by using an inferior
solution that limits or delays progress considerably and results in more bug
reports with zillions of dupes...

[1] http://www.gentoo.org/proj/en/portage/doc/common-problems.xml

Bo Andresen
Old 12-21-2007, 02:35 PM
Bo Ørsted Andresen
Default Use EAPI-suffixed ebuilds (.ebuild-EAPI)

On Thursday 20 December 2007 17:14:52 Thomas Pani wrote:
> > Are we Debian now? A new feature gets implemented (obviously because we
> > *need* it) and we can make use of it in a *year*?
> No, we're not Debian, thank god. I thought the "wait 1+ year" policy
> changed? Again citing Ciaran: "That was only the case because
> previously, using new features that Portage didn't support would cause
> horrible breakage. Now, instead, the ebuilds show up as being masked." [2]

It has changed as long as you don't introduce features that makes old versions
of portage fail to source the ebuild. EAPI=1 didn't do that.

Bo Andresen
Old 12-21-2007, 02:40 PM
Bo Ørsted Andresen
Default Use EAPI-suffixed ebuilds (.ebuild-EAPI)

On Thursday 20 December 2007 22:33:25 Joe Peterson wrote:
> Technical reasons to avoid the filename are:
> 2) Having the same info in more than one place is bad (requiring extra
> repoman checks and the potential for ambiguity).

As opposed to adding checks to make sure that obtaining the EAPI from the
contents of the file doesn't require bash?

> 3) It uses the extension in a way that goes against common use in computers.

What? It uses the extension to determine the format of the contents?

Bo Andresen
Old 12-21-2007, 02:41 PM
Bo Ørsted Andresen
Default Use EAPI-suffixed ebuilds (.ebuild-EAPI)

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

Bo Andresen
Old 12-21-2007, 02:45 PM
Bo Ørsted Andresen
Default Use EAPI-suffixed ebuilds (.ebuild-EAPI)

On Friday 21 December 2007 05:46:35 Josh Saddler wrote:
> Who cares? Gentoo uses the ebuild/bash-with-shebang format. If you're
> trying to shove in something outside of that, that would be a package
> manager-specific format. Like XML-stuff (that can't include the shebang
> or EAPI="foo" at the top) specifically for, say, Paludis.

GLEP means Gentoo Linux Enhancement Proposal. It was proposed to enhance
Gentoo... Paludis already supports this kind of thing for usage outside
gentoo-x86. That has no relevance to Gentoo unless the GLEP gets approved...

Bo Andresen
Old 12-21-2007, 03:37 PM
Joe Peterson
Default Use EAPI-suffixed ebuilds (.ebuild-EAPI)

Assuming that the file extension must change to prevent current PMs from
trying to parse new format ebuilds (and not require waiting a year or
more), I'd be a lot happier seeing it change *once* to a new fixed
extension, with the requirement that the new ebuilds are required to
contain within them them EAPI. This should future-proof the system.

Preferably, shorten the extension and make a new standard. I noticed
that ".eb" seems to be unused
gentoo-dev@gentoo.org mailing list
Old 12-21-2007, 05:52 PM
Petteri Räty
Default Use EAPI-suffixed ebuilds (.ebuild-EAPI)

Richard Freeman kirjoitti:
> 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...

EAPI=foo is already in skel.ebuild but it's commented because EAPI 1
should only be used when there is a need for the new features.

Old 12-21-2007, 11:23 PM
Default Use EAPI-suffixed ebuilds (.ebuild-EAPI)

Zhang Le <r0bertz@gentoo.org> posted 476B3DCE.6080801@gentoo.org,
excerpted below, on Fri, 21 Dec 2007 12:15:10 +0800:

> Ciaran McCreesh wrote:

>> Package manager EAPIs don't belong in the main tree, but they have uses
>> outside of it.
> Then would you please introduce how paludis-1 EAPI differs from official
> EAPI's?

Agreed with Ciarn here. Certain PMs, call them super-PMs if you will,
wish to work with formats other than Gentoo formats, with an ultimate
goal of working with distributions other than Gentoo. If it's not for
use in the main tree, how does it affect Gentoo, and if it doesn't affect
Gentoo, how is it on topic here?

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-21-2007, 11:59 PM
Steve Long
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:
>> >> No: without knowing the EAPI when generating said data. If that
>> >> needs to be known relatively soon in order to generate the rest,
>> >> extract it early. You still only need to load the file from disk
>> >> once, and you don't need to source to get that data, given one
>> >> simple restriction (only declaring it once.)
>> >
>> > You can't get the EAPI from the ebuild without knowing what EAPI the
>> > ebuild uses. That's one of the points you're missing.
>> >
>> Wow that doesn't half sound like nonsense.
> Unfortunately, it's not nonsense. It's entirely true. If you don't
> understand that then you can't contribute anything useful to the
> discussion, so kindly stay out of it.
[This (along with your stubborn refusal to ever explain anything) is what I
mean by your manner not inviting discussion.]

The datum you want is in a line in the file, easily extractable without
sourcing. If you don't understand that it provides the same functionality,
kindly go back to Uni and ask them to take your degree back.

>> An EAPI="blah" at top-level in the file is exactly the same as the
>> suffix in terms of what can be represented
> But not in what can be changed.
Nonsense: if the file isn't source'able the package manager will know this
due to the EAPI line giving an unknown key, and won't bother doing anything
else with it.

You can put whatever you want in there as long as you have the EAPI

>> According to the original discussion this was always supposed to be a
>> variable set in the ebuild source:
> And things moved on. Right back when this first came up several people
> pointed out why a variable isn't an optimal solution.
You can't even be bothered to provide a link, let alone any sort of
explanation. You haven't explained at any point why a line in the ebuild is
so unacceptable, yet you keep asserting that it's already been established
that it won't work. Even though that was the design that was originally
agreed upon, back when you were still a Gentoo dev.

>> At that time others made the case for restricting its format in
>> exactly the same way you have been resisting for the ebuild source,
>> but see as fine for tacking onto the end of the filename:
>> "I would also suggest requiring that EAPI can be retrieved by a
>> simple line by line parsing without using bash. (This allows for
>> changing the parsing system)"[2]
> Except that that proposal doesn't work, as we've already established.
No you just state it, in other threads too. That's not establishing
anything, and certainly not consensus.

It is trivial to extract one line and gives the information required without
sourcing. In effect, it's stating that the one thing which can't be dynamic
in an ebuild is the EAPI setting, which your proposal requires as well.

>> The idea of a different suffix was discussed back then as well:
>> "portage *should not* ignore those ebuilds. If the user
>> wants to merge something that is a later ebuild api then they have,
>> at least portage chucks an exception that the UI can wrap into
>> 'upgrade portage'.
> There are times when the ebuilds have to be ignored.
Yes and if the EAPI is unsupported the manager can skip it.

>> With what you're proposing, we instead get bugs about portage missing
>> packages."[3]
> Only when absolutely necessary -- and it's only absolutely necessary
> when introducing changes such as version suffix extensions that would
> result in packages not being usable anyway.
Yeah kinda like the idea of having an EAPI setting in the ebuild so that the
manager can ignore it if it uses unsupported extensions, or even a
different language.

>> > It's an ebuild issue, not a package manager issue.
>> >
>> You keep saying that; sure EAPI is visible to ebuild and maintainer
>> (doh) but the reason you have stated for this change in file naming
>> (which is a lot more far-reaching than a simple restriction on the
>> format of a variable) is so that the *PM* doesn't have to source the
>> ebuild to get the EAPI.
> It's so that the ebuild's EAPI can be extracted. The way things are
> currently, there is no way to get an ebuild's EAPI without already
> knowing its EAPI.
Like I said, it's trivial to extract a line from the ebuild without
sourcing. You know it is, and so does everyone else.

>> > You're confusing the two different types of metadata. Which again
>> > shows that you need to start understanding the metadata process
>> > before trying to discuss design decisions relating to it...
>> >
>> It doesn't make any practical difference[4]: the computational issue
>> is how to avoid a source statement via bash from another language.
>> I note in passing that a metadata cache is available, with no runtime
>> requirement on the user's part, since it is taken from the rsync'ed
>> data.
> And *again* you demonstrate that you don't understand the metadata
> process. The metadata cache cannot be generated without already knowing
> the ebuild's EAPI, which is part of its metadata.
So extract the line and get the value, and stop pretending this is some
mystic art only you and the people who agree with you have the ability to
comprehend. It's coding, and yeah it's tricky sometimes, but it's being run
by a CPU; if you can explain it to the computer you can explain it to
someone else (if you want to; if all you're about is putdowns, ofc, you
can obfuscate and take 5 mails to get across what could have been done in
1, all the while telling the people who have no choice but to deal with you
that it's all their problem. Asperger's is bad, m'kay?)

>> >> (optimising early here seems silly tbh, given that paludis now
>> >> requires ruby.)
>> >
>> > Eh? Now what're you on about?
>> >
>> http://bugs.gentoo.org/show_bug.cgi?id=198864
> Thankyou for demonstrating to everyone that you don't know what a USE
> flag is.
Eh, no I had thought that the reason people have been complaining about
paludis bloat and forcing make -j0 (512MB of RAM required per make process)
was the dep on ruby. Clearly you can bloat it all on your own.

>> >> > There is currently no information available from an ebuild that
>> >> > can be parsed by any tool other than bash.
>> >> >
>> >> OK, but restricting EAPI= across the board (in the way that others
>> >> have already asked for) and enforcing it via repoman would mean
>> >> EAPI could easily be extracted.
>> >
>> > Except that it's an arbitrary, pointless restriction.
>> >
>> Er arbitrary, no, since in practise it means exactly the same thing
>> as the filename suffix (one single string declaration.) Pointless not
>> at all, since it allows you to avoid calling bash and waiting for it
>> to source, without an ugly hack. It also keeps the existing work
>> practises that everyone is used to and doesn't mandate any changes to
>> support tools.
> ...and imposes arbitrary, pointless restrictions upon the format, which
> is exactly what EAPI is supposed to prevent.
Rubbish: it imposes a restriction on ONE line of the whole thing. And the
restriction on the format of that item, is less than the restrictions
implicit in making it a file suffix.

>> >> Since only declaring it the once /seems/ ok with you, what on Earth
>> >> is so hard about extracting it?
>> >
>> > With the current situation, the EAPI has to be known for the EAPI
>> > to be calculated. Adding in a pre-pass layer enforcing new file
>> > format restrictions does not solve the problem we're trying to
>> > address.
>> >
>> There is no pre-pass layer enforcing restrictions (nice FUD though);
> No, there's a pre-pass layer which by its existence enforces
> restrictions.
You just said we were adding it with the "file format restrictions" on one
line of the ebuild; I simply pointed out that it doesn't have to be checked
by the package manager. That means the limited restriction (which no-one
minds) enforced by repoman is not "adding in a pre-pass layer enforcing new
file format restriction" as you incorrectly stated.

Honestly it's hard to keep with what you think you're talking about; one
minute things have to be very restricted, the next we have to support use
cases no-one is interested in. You wade into a sub-thread and apparently
forget the code example under discussion, even though it's in the prior
mail, yet insist that everyone else *research* your words; and not only
across threads, no we apparently have to read through your code as well as
your frankly unpleasant words, simply to get an idea of what problem you
think this is solving.

Not conducive to Free software development, not what the Gentoo community is
about (or at least, not the one I enjoy) and certainly not my idea of fun.

gentoo-dev@gentoo.org mailing list
Old 12-22-2007, 12:19 AM
Steve Long
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..
"We generally make sure that the tree is compatible with portage versions
released in the past six months, so if you don't have version released in
that timeframe it is possible that you won't be able to use the tree

What applications are so important that require this change in order to
work, that we have to go through the tool modifications now rather than
wait a few months and let the newer versions of portage deal with it,
without us having to make any changes at all?

After all we can use EAPI="1" already, and if the portage team want to put
more features in, they're at liberty to define EAPI="2" or any other.

It appears this is being rushed through: we can have some undefined new
features (well Paludis users can) now, if only we allow unbounded changes
to the filename suffix. That's not a good enough reason.

[1] http://www.gentoo.org/proj/en/portage/doc/common-problems.xml

gentoo-dev@gentoo.org mailing list

Thread Tools

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

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