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-27-2007, 06:48 PM
Marius Mauch
 
Default Use EAPI-suffixed ebuilds (.ebuild-EAPI)

On Thu, 20 Dec 2007 17:22:22 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:

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

Unfortunately the "emerge --eapi $foo" part would be passed as a single argument to /usr/bin/env, therefore can't work.

Marius
--
gentoo-dev@gentoo.org mailing list
 
Old 12-27-2007, 07:15 PM
Marius Mauch
 
Default Use EAPI-suffixed ebuilds (.ebuild-EAPI)

On Thu, 20 Dec 2007 09:55:06 +0000
Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> wrote:

> > > > Stuck ranges into metadata.xml for which EAPIs applied?
> > >
> > > No package manager required information can be in XML format.
> >
> > Says who? Us. We can change that, if we decide it's the best answer.
> > =)
>
> Say the Portage people for the past lots of years.

I assume you're referring to some statements I and maybe Nick made several years ago, I don't think Brian, Jason or Zac ever really thought about it. I can only speak for myself, but those past statements were mostly due to experiences made with glsa-check and issues in the python/pyxml relationship (in 2003), things may have changed since then so those statements could be re-evaluated.

Marius
--
gentoo-dev@gentoo.org mailing list
 
Old 12-27-2007, 07:28 PM
Michael Haubenwallner
 
Default Use EAPI-suffixed ebuilds (.ebuild-EAPI)

On Thu, 2007-12-27 at 20:48 +0100, Marius Mauch wrote:
> On Thu, 20 Dec 2007 17:22:22 +0100
> Luca Barbato <lu_zero@gentoo.org> wrote:
>
> > I'm thinking about having them embedded in the comment as first line as
> > something like
> >
> > #!/usr/bin/env emerge --eapi $foo
>
> Unfortunately the "emerge --eapi $foo" part would be passed as a single argument to /usr/bin/env, therefore can't work.

This also could be done as (using 'ebuild' instead of 'emerge')

#! /usr/bin/env ebuild.1

and PM could provide some 'ebuild.1' executable, at the bare mimimum
doing nothing but

#! /bin/sh
exec ebuild --eapi 1 "$@"

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

--
gentoo-dev@gentoo.org mailing list
 
Old 12-27-2007, 07:36 PM
Ciaran McCreesh
 
Default Use EAPI-suffixed ebuilds (.ebuild-EAPI)

On Thu, 27 Dec 2007 21:28:41 +0100
Michael Haubenwallner <haubi@gentoo.org> wrote:
> This also could be done as (using 'ebuild' instead of 'emerge')
>
> #! /usr/bin/env ebuild.1
>
> and PM could provide some 'ebuild.1' executable, at the bare mimimum
> doing nothing but
>
> #! /bin/sh
> exec ebuild --eapi 1 "$@"

But *why*? We've finally almost gotten people away from installing
things using ebuild. Why on earth would we want to bring it back?

The correct way to install a package is through the nice, friendly,
mask checking, dependency resolving package manager frontend. There is
no correct action that can be taken when an ebuild is executed on its
own, so ebuilds shouldn't be executable on their own.

--
Ciaran McCreesh
 
Old 12-28-2007, 04:43 AM
Steve Long
 
Default Use EAPI-suffixed ebuilds (.ebuild-EAPI)

Ciaran McCreesh wrote:
>> > c) It's an extremely bizarre restriction, the likes of which do not
>> > currently exist, that will confuse the hell out of all the people
>> > that don't realise that such a restriction exists.
>>
I don't think it's that hard to understand "You can only set EAPI *once* in
your ebuild." Are you really saying devs won't get that?

Who are these mythical "people"? Devs take a quiz: the EAPI setting
restrictions can easily be added to it, as well as being documented
elsewhere.

That would of course have to be done doubly so for your GLEP, which imposes
a much more bizarre restriction: that the EAPI must go in the filename.

>> Devs are already used to follow numerous conventions in the way they
>> format their ebuilds.
>
> And they already arbitrarily don't follow them. We get people screwing
> up whitespace and brackets in dep strings, for example (Portage doesn't
> error check these very well).
>
Odd: I found repoman very fussy about those. Leaving the digs at portage
aside, that's what the new commit reviews are about.

>> > d) It introduces a new prepass parse layer to an already complex
>> > process.
>>
>> Both solutions add some new steps to this process, and it doesn't look
>> to me like there's a significant difference beetween their respective
>> added complexity. That said, you're the PM dev here, not me, so if
>> you confirm that implementation of an in-contents solution is
>> significantly harder, then i will accept the argument.
>
> It's not harder (assuming the syntax is well defined -- single, double
> or no quotes? export? leading whitespace? is it the first or the last
> match of EAPI="" that's taken?). It's just messy, because we'd have to
> deal with stupid cases like:
>
> DESCRPTION="Config file to make Paludis support
> EAPI='4' packages"
>
Wow, yet another contrived b0rkage. You really don't have a very high
opinion of Gentoo devs, do you?

> EAPI="1"
> export EAPI=2
>
> src_compile() {
> cat <<END > somefile
> EAPI=3
> END
> }
>
All those would be dealt with by the well-defined syntax. I'd start with:
EAPI="foo" on its own on a line. The first setting is taken.

>> > e) The Portage guys said no to it.
>>
>> When/where? I've only seen Marius commenting here, but not on that
>> aspect. Also, i've read this 2005 "EBUILD_FORMAT" discussion that
>> Steve Long has pointed [1], where Brian was against non-Bash parsing,
>> but:
>> - he was against changing files extension too,
>> - the flaws in the EAPI system designed at this time is what led to
>> rethinking it now.
>>
>> If i've missed something since then (and that's likely), could you
>> give me a pointer to the archives? Thanks.
>
> A while after that Brian and I had a huge lengthy argument on IRC about
> it. I don't have IRC logs that far back, which is kind of a shame
> because we covered pretty much all of the things that people are
> moaning about now...
>
Somehow I'm not reading "Brian and I agreed that.." and it concerns me that
we haven't so far had portage and pkgcore devs chiming in that your GLEP is
just what they want as the solution to several issues, meriting the work
required to change over, and the future hackiness and restrictions it
imposes.

>> My point here is that the in-contents alternative is just a syntaxic
>> rule which defines a first-pass extraction of a value from an ebuild
>> file (as opposed to an ebuild file name extension). How it is then
>> used (what the "eapi" function does, if anything, or whether this
>> value is the definitive EAPI, or how EAPI vs. eclasses is handled,
>> etc.) can be subject to future changes depending on this value. That's
>> part of why this solution is not more restrictive than the file name
>> extension approach.
>
> But then you get the highly weird result of setting, say, EAPI="4" in
> the ebuild but the c/p-v actually having EAPI="3" because of weird hard
> to see behind the scenes eclass voodoo.
That sounds like a borked package manager, and something which should not be
allowed per the spec. If an ebuild author sets EAPI that's what the
metadata EAPI must reflect.

> That's equivalent to the "using
> the wrong file extension and then overriding with a variable"
> situation, except that you're effectively requiring it for future
> changes rather than making it something that's a big flashy warning.
>
Or you're just contriving examples.

> (From a technical perspective, changing EAPI mid-source is a massive
> pain in the ass. EAPI pretty much has to be able to tinker with PATH
> and friends, and there's no sane way of modifying variables as soon as
> another variable changes.
It's up to the eclass/ebuild author to deal with the consequences of code
they write. In the same light, it's up to the PM devs to ensure that the
EAPIs they support work correctly.

> For example, and not saying that this
> specific case is desirable, EAPI foo could require that the first 'sed'
> in PATH be GNU sed, whilst EAPI bar could require that it be the normal
> system sed.)
>
If you could come up with a more cogent example (that actually poses a
technical challenge) perhaps your peers can help you with the difficulties
you are having. That's what a dev mailing list is for.


--
gentoo-dev@gentoo.org mailing list
 
Old 12-28-2007, 10:34 PM
Duncan
 
Default Use EAPI-suffixed ebuilds (.ebuild-EAPI)

Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> posted
20071228122810.1bbe2637@blueyonder.co.uk, excerpted below, on Fri, 28 Dec
2007 12:28:10 +0000:

> On Fri, 28 Dec 2007 13:25:13 +0100
> "Santiago M. Mola" <coldwind@gentoo.org> wrote:
>> On Dec 28, 2007 1:03 PM, Ciaran McCreesh
>> <ciaran.mccreesh@blueyonder.co.uk> wrote:
>> > There's no particular reason that new version formats can't be
>> > introduced in a new EAPI so long as the version strings don't appear
>> > in ebuilds using older EAPIs or in profiles. Ditto for naming rules.
>>
>> Errr... so should we use new files in profiles for such new formats?
>> (for example, p.masking an ebuild with a new version format).
>
> Possibly. Currently there's simply no way of doing it, nor of using
> non-EAPI-0 features anywhere in profiles (you can't, for example, use
> slot deps in package.mask).

Requesting clarification of a point, here:

I understand the ban on non-EAPI-0 features in in-tree profiles, since
users could be using old PMs, but it's fine using them in /etc/portage/*,
provided one has upgraded to an appropriately compatible PM, correct?

I ask because based on the kde overlay documentation, I have a lot of
entries like this in /etc/portage/package.keywords:

# kde4 overlay kde-base
kde-base/kdelibs:kde-svn **

--
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-29-2007, 06:07 PM
Ciaran McCreesh
 
Default Use EAPI-suffixed ebuilds (.ebuild-EAPI)

On Fri, 28 Dec 2007 23:34:44 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:
> I understand the ban on non-EAPI-0 features in in-tree profiles,
> since users could be using old PMs, but it's fine using them
> in /etc/portage/*, provided one has upgraded to an appropriately
> compatible PM, correct?

Config files are entirely up to your package manager of choice.

--
Ciaran McCreesh
 
Old 12-31-2007, 01:48 PM
Marius Mauch
 
Default Use EAPI-suffixed ebuilds (.ebuild-EAPI)

On Fri, 28 Dec 2007 23:34:44 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> I understand the ban on non-EAPI-0 features in in-tree profiles, since
> users could be using old PMs, but it's fine using them in /etc/portage/*,
> provided one has upgraded to an appropriately compatible PM, correct?

Yes (in case of portage).

Marius
--
gentoo-dev@gentoo.org mailing list
 

Thread Tools




All times are GMT. The time now is 05:38 AM.

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