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-13-2007, 03:16 PM
Petteri Räty
 
Default EAPI placement

Ciaran McCreesh kirjoitti:
> On Wed, 12 Dec 2007 15:08:36 +0100
> "Santiago M. Mola" <coldwind@gentoo.org> wrote:
>> Would it be possible to have eclass/eapiBLAH/foo.eclass?
>
> No. Not even with an EAPI change. This is one of the deficiencies in
> the way EAPI was designed -- an EAPI cannot change the behaviour of
> inherit, nor can it introduce new global-scope functions.
>

Actually adding new global scope functions is possible with the help of
base/profile.bashrc . We can use that file to add stubs so that sourcing
the ebuild still works. The only restriction is that the new function
can't be used to evaluate the value of EAPI.

Regards,
Petteri
 
Old 12-15-2007, 08:43 AM
Vlastimil Babka
 
Default EAPI placement

Ciaran McCreesh wrote:
> On Wed, 12 Dec 2007 23:14:24 +0100
> Carsten Lohrke <carlo@gentoo.org> wrote:
>> I disagree here. It would be annoying and possibly even hindering in
>> future not being able to use higher EAPI features in eclasses. Point
>> is the eclass has to check, if the author of an ebuild sets another
>> EAPI and throw an error, in this case.
>
> There is no way for an eclass to throw an error. Nor, with the current
> way Portage implements EAPI, is there a way to add such a way.

How bout declaring all supported (possibly with later conditional checks
on EAPI variable etc) EAPIs in eclass via some variable, and repoman
checking that EAPI set in the ebuild is compatible with all inherited
eclasses? And if you need newer EAPI in the ebuild, get eclasses updated
first (even if its just updating the compatibility declaration).
Also, repoman could check that EAPI is not being set in the eclass.

VB
--
gentoo-dev@gentoo.org mailing list
 
Old 12-15-2007, 11:20 AM
Marius Mauch
 
Default EAPI placement

On Sat, 15 Dec 2007 10:43:35 +0100
Vlastimil Babka <caster@gentoo.org> wrote:

> Ciaran McCreesh wrote:
> > On Wed, 12 Dec 2007 23:14:24 +0100
> > Carsten Lohrke <carlo@gentoo.org> wrote:
> >> I disagree here. It would be annoying and possibly even hindering
> >> in future not being able to use higher EAPI features in eclasses.
> >> Point is the eclass has to check, if the author of an ebuild sets
> >> another EAPI and throw an error, in this case.
> >
> > There is no way for an eclass to throw an error. Nor, with the
> > current way Portage implements EAPI, is there a way to add such a
> > way.
>
> How bout declaring all supported (possibly with later conditional
> checks on EAPI variable etc) EAPIs in eclass via some variable, and
> repoman checking that EAPI set in the ebuild is compatible with all
> inherited eclasses? And if you need newer EAPI in the ebuild, get
> eclasses updated first (even if its just updating the compatibility
> declaration). Also, repoman could check that EAPI is not being set in
> the eclass.

Nice idea, but gets quite complicated when multiple (possibly nested)
eclasses are involved as we'd have to generate a complete inheritance
graph and get that new variable separately for each eclass. Or
alternatively each eclass has to update the variable with the
intersection between the old value and it's own set of supported EAPIs.

And doesn't really solve the problem, just reduces the scope a fair bit
(e.g. if an eclass drops support for an EAPI version repoman will only
catch it gradually if the packages using it are bumped, unless you
manually check the whole tree).

Marius
--
gentoo-dev@gentoo.org mailing list
 
Old 12-22-2007, 03:00 PM
Carsten Lohrke
 
Default EAPI placement

On Mittwoch, 12. Dezember 2007, Santiago M. Mola wrote:
> Nobody said that eclasses can't use new features.

Using new features in ebuilds or eclasses relates. EAPI A using ebuild with
EAPI B using eclass (but not defining any EAPI) is your hard nut. Shouldn't
happen, but will. And bugs in eclasses unfortunately don't have a minor
impact.

> Just that they
> cannot _set_ EAPI or assume they are working with any EAPI.

And I say they can - under the condition that you have a defined subset of
ebuilds belonging to that eclass.

> Yep, that issue should be addresses as it is in paludis and pkgcore.

Neither one is Gentoo's package manager Please spare me an answer.


Carsten
 
Old 12-22-2007, 03:27 PM
Carsten Lohrke
 
Default EAPI placement

On Mittwoch, 12. Dezember 2007, Ciaran McCreesh wrote:
> On Wed, 12 Dec 2007 23:14:24 +0100
> There is no way for an eclass to throw an error. Nor, with the current
> way Portage implements EAPI, is there a way to add such a way.

It's not perfect, but

<eclass>_pkg_setup() {
something_wrong && die
}

should work reasonably well.


> It's in PMS. svn co http://svn.repogirl.net/pms for a copy.

Right. But when you think every dev will read the PMS to find out what's fine
to do and what not for N++ EAPIs again and again, while he wants only a short
list of do's and don'ts, your bathing temperature is far above average.

What I do think - and no, I won't read this rediculous large
category/ebuild-x.y-rN-my.local.version-too-much-coffein-drinks.ebuild-epaiN-anyone-else-with-a-stupid-idea
thread - is, that EPAI changes and there implications apparently have not
been well thought out and the best we can do is to ensure there are as few
eclass/ebuild-relating differing EAPIs as possible.


Carsten
 
Old 12-24-2007, 04:51 AM
Steve Long
 
Default EAPI placement

Carsten Lohrke wrote:
> On Mittwoch, 12. Dezember 2007, Ciaran McCreesh wrote:
>> * Eclasses may not set EAPI.
>>
>> * Eclasses may not assume a particular EAPI.
>
> I disagree here. It would be annoying and possibly even hindering in
> future not being able to use higher EAPI features in eclasses. Point is
> the eclass has to check, if the author of an ebuild sets another EAPI and
> throw an error, in this case.
>
Agreed. There's no problem from the bash side of this, only the PM specific
code.

> The most basic issue, which we didn't even discuss yet, afaik, is how to
> make every developer aware which feature belongs to which EAPI. I freely
> admit, I do not know that. Is there a list somewhere?
>
Well the official one is the internal Gentoo PMS repo. The Council haven't
changed the policy so far this term on what is the "authoritative" PMS.
(Nor of course have they accepted any of the drafts officially.)

> EAPI issues may lead to a lot of confusion and eclass bloat, especially
> since we still can't remove stale eclasses afaik.
>
Another maintenance headache, agreed.

Is it possible to remove an eclass if it can be shown that there are no apps
in the tree using it, say for over 2 years? That would give Gentoo
equivalence with longer-term "support" from other distros, while allowing
some breathing space wrt installed ebuilds. It'd be easy enough to automate
a hook to move deleted eclasses to local overlay as well.

> On Mittwoch, 12. Dezember 2007, Santiago M. Mola wrote:
>> Nobody said that eclasses can't use new features.
>
> Using new features in ebuilds or eclasses relates. EAPI A using ebuild
> with EAPI B using eclass (but not defining any EAPI) is your hard nut.
> Shouldn't happen, but will. And bugs in eclasses unfortunately don't have
> a minor impact.
>
>> Just that they
>> cannot _set_ EAPI or assume they are working with any EAPI.
>
> And I say they can - under the condition that you have a defined subset of
> ebuilds belonging to that eclass.

And it's a major loss of flexibility in addition to the maintenance problems
you highlight. A dynamic EAPI declaration in an ebuild is foolish, but
testing the EAPI value in an eclass and taking alternative action, or
indeed allowing dynamic setting in that context (which would require
additional metadata-- in this case i think the overhead is worth it, given
that eclasses are much less numerous than ebuilds, and it's actually
*adding* to what we can do already) makes a lot more sense.

<zlin> the kde4 eclasses in the kde4-experimental overlay set eapi=1.
<zmedico> it's fine to do that, it's just too early to do that on lots
of eclasses in the main tree, because EAPI=1 is too new

So there's no technical reason not to to, apart from some concern about
signalling die()?

<Cardoe> I think putting EAPI above inherit is bad
<Cardoe> because you're relying on the ebuild author to audit all the
eclass code to know which EAPI version is required

Ouch. Well at least EAPI anything is still experimental atm. Thank heavens
for peer review


--
gentoo-dev@gentoo.org mailing list
 
Old 12-24-2007, 07:27 AM
Duncan
 
Default EAPI placement

Steve Long <slong@rathaus.eclipse.co.uk> posted
fknh2s$59n$1@ger.gmane.org, excerpted below, on Mon, 24 Dec 2007 05:51:34
+0000:

>> The most basic issue, which we didn't even discuss yet, afaik, is how
>> to make every developer aware which feature belongs to which EAPI. I
>> freely admit, I do not know that. Is there a list somewhere?
>>
> Well the official one is the internal Gentoo PMS repo. The Council
> haven't changed the policy so far this term on what is the
> "authoritative" PMS. (Nor of course have they accepted any of the drafts
> officially.)

The problem right now is that while you are correct, that's the official
list, due to technical/political issues, the Gentoo-official PMS repo
doesn't (or didn't as of the last council meeting, according to the log)
have any EAPI-1 info at all, as it's currently outdated, with the work
all going into the off-Gentoo repo. (Apparently, there aren't any
official Gentoo devs working on PMS ATM. =8^( Did I mention political
issues in addition to technical ones?)

Thus, one can get detailed but unofficial specs from the informal non-
Gentoo repo, or a general summary as in the new-version portage
announcement mentioning EAPI-1 support, now, or look at the code of the
various PMs. =8^(

>> EAPI issues may lead to a lot of confusion and eclass bloat, especially
>> since we still can't remove stale eclasses afaik.
>>
> Another maintenance headache, agreed.
>
> Is it possible to remove an eclass if it can be shown that there are no
> apps in the tree using it, say for over 2 years? That would give Gentoo
> equivalence with longer-term "support" from other distros, while
> allowing some breathing space wrt installed ebuilds. It'd be easy enough
> to automate a hook to move deleted eclasses to local overlay as well.

Well... according to the portage devs (as posted on the portage devel
list) newer portage now stores the complete build environment, including
the state of all inherited eclasses at the time of the original merge,
and uses them at unmerge if at all possible. If the merge was from an
older version before this info was stored, or if the package database is
corrupted and thus is otherwise missing the complete eclass info, portage
can and does still pull from the live tree.

Thus, in theory, a year or so after the first version with that
functionality working goes/went stable (I don't track stable status as
I'm on ~arch, so I've no idea if it's stable yet or not, or for that
matter which version first qualified), it should then be possible to
start removing old/stale eclasses, keeping in mind that even after they
are removed, if someone /really/ needs them, they can still fetch them
out of the source control system attic.

So in any case, it should be possible <2 years from now; just not yet.

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

Thread Tools




All times are GMT. The time now is 02:44 AM.

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