Re: [gentoo-dev] 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
_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
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] 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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI placement
On Sat, 15 Dec 2007 10:43:35 +0100 Vlastimil Babka <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > > On Wed, 12 Dec 2007 23:14:24 +0100 > > Carsten Lohrke <[EMAIL PROTECTED]> 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 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI placement
Ciaran McCreesh wrote: > On Wed, 12 Dec 2007 23:14:24 +0100 > Carsten Lohrke <[EMAIL PROTECTED]> 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 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI placement
Ciaran McCreesh kirjoitti: > On Wed, 12 Dec 2007 15:08:36 +0100 > "Santiago M. Mola" <[EMAIL PROTECTED]> 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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] EAPI placement
On Tue, 11 Dec 2007 20:00:51 -0500
Doug Klima <[EMAIL PROTECTED]> wrote:
> When you could simply have $pkg_manager execute an eclass as 1
> EAPI, another eclass as another and the ebuild as a third EAPI and
> simplify it for the eclass maintenance.
Which doesn't work at all. Simple example would be the introduction of
new phases, e.g. src_configure with EAPI=2:
foo.eclass:
EAPI=2
setup_env {
# do some stuff that differs betwwen EAPI-1 and EAPI-2
}
src_configure {
econf --some-special-eclass-option
}
bar.ebuild:
inherit foo
EAPI=1
setup_env
# no src_* functions defined
Now should the package manager execute src_configure or not? And that's
assuming we actually track all values of EAPI and their origin as well
as the origin of all functions/variables in the current environment.
Or should setup_env be executed with EAPI=1 (as it's called in the
ebuild) or EAPI=2 (as it's defined in the eclass)? There are no real
answers to those problems.
Marius
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI placement
On Wed, 12 Dec 2007 23:14:24 +0100 Carsten Lohrke <[EMAIL PROTECTED]> 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. > 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? It's in PMS. svn co http://svn.repogirl.net/pms for a copy. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI placement
On Dec 12, 2007 11:14 PM, Carsten Lohrke <[EMAIL PROTECTED]> 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. Nobody said that eclasses can't use new features. Just that they cannot _set_ EAPI or assume they are working with any EAPI. But an eclass can check which EAPI is set in the environment (that's which EAPI the ebuild set) and act accordingly, using features available on that EAPI. > > 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? EAPIs are defined in PMS [1] although I don't find an "officla" copy at gentoo.org (only the one in dev.g.o/~spb). > > EAPI issues may lead to a lot of confusion and eclass bloat, especially since > we still can't remove stale eclasses afaik. > Yep, that issue should be addresses as it is in paludis and pkgcore. [1] http://www.gentoo.org/proj/en/qa/pms.xml -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI placement
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. 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? EAPI issues may lead to a lot of confusion and eclass bloat, especially since we still can't remove stale eclasses afaik. Carsten signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI placement
Ciaran McCreesh wrote: > On Wed, 12 Dec 2007 09:20:02 -0500 > Doug Klima <[EMAIL PROTECTED]> wrote: > >> And I brough up valid reasons with zmedico why putting it before the >> inherit line was flawed currently since it could lead to some >> seriously unexpected behavior. >> > > It's only unexpected if people screw up. If everyone understands the > restrictions I posted and sticks to them then things work. If people > start trying to be clever things go horribly wrong. > > >> If that's the case, it needs to be a >> very strict check in repoman and we need repoman on the eclasses to >> prevent people from putting EAPI into the eclasses. >> > > Or you need to get PMS and package managers retroactively updated to > saying that 'inherit' does a 'declare -r EAPI'... Although that's only > a good idea if you operate on the assumption that developers will screw > up. > > That's the assumption I'm operating under because you and I both know if repoman and friends don't prevent it, it will happen. We can have all the docs in the world, but if we don't go about some steps to prevent bad things from happening. They can and will. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI placement
On Wednesday 12 of December 2007 15:20:19 Ciaran McCreesh wrote: > The .ebuild-eapi proposal didn't have this problem, but unfortunately it > was rejected for political reasons... I wasn't around then, but the requirment of actually sourcing the ebuild to read the EAPI value is extremely stupid indeed. Let's change it... -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI placement
On Wed, 12 Dec 2007 09:22:41 -0500 Doug Klima <[EMAIL PROTECTED]> wrote: > My point is it's fine to state this, however there needs to be > enforcement of this in the associated utilities. repoman, etc. > Unfortunately, eclasses are not checked at all at commit time, which > would allow developers to make this potentially catastrophic change. Well, the other option is to enforce it via the package manager. But that's enforcing tree policy via EAPI, which we were trying to avoid. > So we're going to have "eapi 1 && inherit foo-eapi1.eclass" allowable > in "foo.eclass"? When will this "eapi" keyword be available for > eclasses to use? [[ $EAPI == 1 ]] Adding an eapi keyword would require a new EAPI, so you'd have to do the variable test for 0 and 1 anyway (and note that the empty EAPI is exactly like EAPI 0, and you can't assume that you'll get one or the other). -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI placement
On Wed, 12 Dec 2007 09:20:02 -0500 Doug Klima <[EMAIL PROTECTED]> wrote: > And I brough up valid reasons with zmedico why putting it before the > inherit line was flawed currently since it could lead to some > seriously unexpected behavior. It's only unexpected if people screw up. If everyone understands the restrictions I posted and sticks to them then things work. If people start trying to be clever things go horribly wrong. > If that's the case, it needs to be a > very strict check in repoman and we need repoman on the eclasses to > prevent people from putting EAPI into the eclasses. Or you need to get PMS and package managers retroactively updated to saying that 'inherit' does a 'declare -r EAPI'... Although that's only a good idea if you operate on the assumption that developers will screw up. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI placement
Ciaran McCreesh wrote: > On Tue, 11 Dec 2007 16:59:28 -0500 > Doug Klima <[EMAIL PROTECTED]> wrote: > >> discuss. >> > > * EAPI may only be set before the 'inherit' in an ebuild. > > * Eclasses may not set EAPI. > > * Eclasses may not assume a particular EAPI. > > * If an eclass needs to work with multiple EAPIs, EAPI-specific code > should be split out into foo-eapiBLAH.eclass, and EAPI-agnostic code > and a conditional inherit should remain in foo.eclass. > > * Eclasses cannot be made not to work with any given EAPI. If such > functionality is desirable, someone needs to file an EAPI request for > permitting an alternative to 'die' that is legal in global scope. > > My point is it's fine to state this, however there needs to be enforcement of this in the associated utilities. repoman, etc. Unfortunately, eclasses are not checked at all at commit time, which would allow developers to make this potentially catastrophic change. So we're going to have "eapi 1 && inherit foo-eapi1.eclass" allowable in "foo.eclass"? When will this "eapi" keyword be available for eclasses to use? -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI placement
On Wed, 12 Dec 2007 15:08:36 +0100 "Santiago M. Mola" <[EMAIL PROTECTED]> 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. The .ebuild-eapi proposal didn't have this problem, but unfortunately it was rejected for political reasons... > > * Eclasses cannot be made not to work with any given EAPI. If such > > functionality is desirable, someone needs to file an EAPI request > > for permitting an alternative to 'die' that is legal in global > > scope. > > So is it desirable? > > If portage masks ebuilds with an unsupported EAPI, what's the point? > It'd be enough to be able to check EAPI compatibility in eclasses > quickly so repoman and others can print a nice error. The problem is that people change eclasses and don't check every single package that uses them. Find a solution for that problem and then eclasses supporting only a subset of EAPIs becomes feasible. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI placement
Petteri Räty wrote: > Doug Klima kirjoitti: > >> Since it doesn't appear the question was answered by the last thread. >> I'm starting a new thread. >> >> > > http://article.gmane.org/gmane.linux.gentoo.devel/52981/match=eapi > > I think it was answered. > > Regards, > Petteri > > And I brough up valid reasons with zmedico why putting it before the inherit line was flawed currently since it could lead to some seriously unexpected behavior. If that's the case, it needs to be a very strict check in repoman and we need repoman on the eclasses to prevent people from putting EAPI into the eclasses. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI placement
On Dec 12, 2007 1:21 PM, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > On Tue, 11 Dec 2007 16:59:28 -0500 > Doug Klima <[EMAIL PROTECTED]> wrote: > > discuss. > > * EAPI may only be set before the 'inherit' in an ebuild. > > * Eclasses may not set EAPI. > > * Eclasses may not assume a particular EAPI. > > * If an eclass needs to work with multiple EAPIs, EAPI-specific code > should be split out into foo-eapiBLAH.eclass, and EAPI-agnostic code > and a conditional inherit should remain in foo.eclass. It seems the most reasonable option I've read until now. Would it be possible to have eclass/eapiBLAH/foo.eclass? > * Eclasses cannot be made not to work with any given EAPI. If such > functionality is desirable, someone needs to file an EAPI request for > permitting an alternative to 'die' that is legal in global scope. So is it desirable? If portage masks ebuilds with an unsupported EAPI, what's the point? It'd be enough to be able to check EAPI compatibility in eclasses quickly so repoman and others can print a nice error. -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI placement
On Tue, 11 Dec 2007 16:59:28 -0500 Doug Klima <[EMAIL PROTECTED]> wrote: > discuss. * EAPI may only be set before the 'inherit' in an ebuild. * Eclasses may not set EAPI. * Eclasses may not assume a particular EAPI. * If an eclass needs to work with multiple EAPIs, EAPI-specific code should be split out into foo-eapiBLAH.eclass, and EAPI-agnostic code and a conditional inherit should remain in foo.eclass. * Eclasses cannot be made not to work with any given EAPI. If such functionality is desirable, someone needs to file an EAPI request for permitting an alternative to 'die' that is legal in global scope. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI placement
Doug Klima kirjoitti: > Since it doesn't appear the question was answered by the last thread. > I'm starting a new thread. > http://article.gmane.org/gmane.linux.gentoo.devel/52981/match=eapi I think it was answered. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] EAPI placement
Marius Mauch wrote: On Tue, 11 Dec 2007 16:59:28 -0500 Doug Klima <[EMAIL PROTECTED]> wrote: Since it doesn't appear the question was answered by the last thread. I'm starting a new thread. The only sane solution I can think of is that eclasses shouldn't be allowed to change EAPI, but use conditionals to behave differently if needed. Mixing two (or more) different arbitrary EAPIs isn't going to work as after the inital parsing package managers will only see the last EAPI value anyway. Also there is no guarantee that future EAPI versions will be backwards compatible, so if eclasses could have an EAPI version it would eventually require that all packages using it need the same EAPI version (similar for nested inheritance). It's trivial to let inherit check that an eclass doesn't modify EAPI, and adding the conditional code to eclasses isn't difficult either: foo.eclass: if [ -z "$EAPI" ]; then inherit foo-eapi0 fi case "$EAPI" in 0) inherit foo-eapi0 ;; 1|2) inherit foo-eapi1_2 ;; *) eerror "foo.eclass: unsupported EAPI value $EAPI" ;; esac # EAPI independent code here Obviously instead of specific eclasses one could also inline the relevant code. The only two issues I see in this concept are the eventual multiplication of eclasses and the lack of proper error handling for unsupported EAPIs. Marius PS: Yes, this idea has been mentioned in the old thread as well This again leads to in a sense, code duplication due to the fact that you have to have several different versions of the code for each EAPI. When you could simply have $pkg_manager execute an eclass as 1 EAPI, another eclass as another and the ebuild as a third EAPI and simplify it for the eclass maintenance. -- Doug Klima <[EMAIL PROTECTED]> http://dev.gentoo.org/~cardoe/ -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI placement
On Tue, 11 Dec 2007 16:59:28 -0500 Doug Klima <[EMAIL PROTECTED]> wrote: > Since it doesn't appear the question was answered by the last thread. > I'm starting a new thread. The only sane solution I can think of is that eclasses shouldn't be allowed to change EAPI, but use conditionals to behave differently if needed. Mixing two (or more) different arbitrary EAPIs isn't going to work as after the inital parsing package managers will only see the last EAPI value anyway. Also there is no guarantee that future EAPI versions will be backwards compatible, so if eclasses could have an EAPI version it would eventually require that all packages using it need the same EAPI version (similar for nested inheritance). It's trivial to let inherit check that an eclass doesn't modify EAPI, and adding the conditional code to eclasses isn't difficult either: foo.eclass: if [ -z "$EAPI" ]; then inherit foo-eapi0 fi case "$EAPI" in 0) inherit foo-eapi0 ;; 1|2) inherit foo-eapi1_2 ;; *) eerror "foo.eclass: unsupported EAPI value $EAPI" ;; esac # EAPI independent code here Obviously instead of specific eclasses one could also inline the relevant code. The only two issues I see in this concept are the eventual multiplication of eclasses and the lack of proper error handling for unsupported EAPIs. Marius PS: Yes, this idea has been mentioned in the old thread as well -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
[gentoo-dev] EAPI placement
Since it doesn't appear the question was answered by the last thread.
I'm starting a new thread.
did we decide where EAPI goes in an ebuild?
yes, just above the inherit
that's the safest and simplest thing to do, anyway
zmedico: what if I have EAPI=2 above the inherit but an eclass
has EAPI=1
then the eclass would override the EAPI
which probably isn't what you want
are there any eclasses defining EAPI now? I hope not. :)
* lavajoe has quit ("Leaving")
I'm not sure
not in gentoo-x86
but I think it would be something that would happen in the future
if an eclass uses features that require a specific EAPI
wouldn't it make sense to list that in there?
the kde4 eclasses in the kde4-experimental overlay set eapi=1.
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
we don't even have stages with EAPI=1 aware portage in them
released yet
it probably shouldn't ever be done in an existing eclass.
I think putting EAPI above inherit is bad
because you're relying on the ebuild author to audit all the
eclass code to know which EAPI version is required
for all the code
same thing if you put it below, no?
no
because the eclass code should get executed at EAPI=1
while the ebuild could get executed at EAPI=2
well, people can hash this stuff out over time
there's no rush
with >=portage-2.1.4 we can make incompatible changes to
eclasses :)
ok but you see what I'm saying?
it should go *AFTER* inherit
to me, mixing code intended for multiple EAPIs is messy
it's conceivable to have 2 different EAPIs where it's not even
possible
While it might be messy, I can guarantee it will happen.
eutils might go to eapi=2 and some ebuild might need eapi=3,
but eutils isn't ported to eapi=3 yet.
If you allow our developers to do it, it will happen.
Plain and simple. Unless repoman blocks this.
we'll have some rules
Ok. Let's establish them.
releasing features and saying "eh.. we'll figure it out as we
go" won't work
because you're gonna find people are going to stick stuff all
over the place from the get go unless there are formal rules now
1) don't do anything stupid without discussing it with the
community first ;)
well, we tried to talk about it on the mailing list but didn't
get a solid answer.
I'm starting a new thread, and including this convo.
that's a too lose rule, people break that on a daily basis in
the tree.
Let's address the issue now, rather then having a broken tree 3
months from now that will require 500 commits to fix.
I'll just send this to the ML now.
discuss.
--
Doug Klima
Gentoo Developer
--
[EMAIL PROTECTED] mailing list
