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 06-10-2008, 07:44 PM
Doug Goldstein
 
Default EAPI-2 - Let's get it started

Fernando J. Pereda wrote:


On 10 Jun 2008, at 18:39, Doug Goldstein wrote:


Nirbheek Chauhan wrote:

On Tue, Jun 10, 2008 at 10:00 PM, Patrick Lauer
<bugs@dev.gentooexperimental.org> wrote:

So EAPI 2 is not "everything shiny", but a small iterative
improvement to

EAPI 1.

Suggest features then and let's discuss!



For reference of existing ideas -- https://bugs.gentoo.org/174380 -- a
tracker for EAPI feature requests.

I personally like https://bugs.gentoo.org/197859 the most -- split out
src_configure from src_compile which will allow sane resuming of
compiles


At this point, we should really only discuss features that all 3
package managers have implemented.


I'm not sure this intersection isn't empty :/

We might, however, only discuss features that all 3 package managers
can implement easily.


- ferdy


That's more of what I meant.
--
gentoo-dev@lists.gentoo.org mailing list
 
Old 06-10-2008, 10:11 PM
Bo Ørsted Andresen
 
Default EAPI-2 - Let's get it started

On Tuesday 10 June 2008 18:26:55 Doug Goldstein wrote:
> Let's try to aim to do an EAPI=2 sometime soonish since Portage now has
> USE flag depends in version 2.2 which is looming on the horizon. It'd be
> nice to hit the ground running with supporting these. I know it'll be
> trivial for the Paludis and pkgcore guys to make this work since they
> already support USE flag depends.

I would like the portage devs to comment upon which of the following features
they think could easily be implemented before portage 2.2 goes stable.
There's still some time since it hasn't left package.mask yet, so I'd rather
they exclude the features that will take too long to implement than anybody
else doing that...

Already implemented:
- Use dependencies, it's not clear to me whether we all agree entirely upon
the syntax yet though (bugs #2272 and #174406)

Things I believe should be trivial to implement:
- Custom output names in SRC_URI, also called arrows (bug #177863)
- Guarantee trailing slashes (bug #174408)
- Limit values in $USE (bug #176467)
- doins support for symlinks (bug #179932)
- Enable FEATURES=test by default (bug #184812)
- GLEP 42 - news items

Bigger features I'm interested in:
- Making do* die on failure by default (without changing their behaviour for
previous eapis). Possibly adding either nonfatal or try_do* for cases where
this isn't desired. (bug #138792)
- More phases
- src_prepare, for applying patches and running autotools etc.
- src_configure, for running configure scripts (bug #197859)
- pkg_pretend (bug #177860 - could also be used to fix bug #75936)
- maint_*, it's not clear to me if this has been fleshed out in sufficient
detail yet (bug #185567)
- default_*, allows an ebuild to redefine phases to add more functionality and
then call default_$phase. Currently the default phases are lost when
redefining the phases.
- default for src_install (bug #33544)
- Ranged dependencies (bug #4315)

Of course I'd like GLEPs 54 and 55 too but since the council still hasn't made
a decision about them I'll leave them out..

--
Bo Andresen
Gentoo KDE Dev
 
Old 06-10-2008, 11:03 PM
Marius Mauch
 
Default EAPI-2 - Let's get it started

On Wed, 11 Jun 2008 00:11:32 +0200
Bo Ørsted Andresen <zlin@gentoo.org> wrote:

> On Tuesday 10 June 2008 18:26:55 Doug Goldstein wrote:
> > Let's try to aim to do an EAPI=2 sometime soonish since Portage now
> > has USE flag depends in version 2.2 which is looming on the
> > horizon. It'd be nice to hit the ground running with supporting
> > these. I know it'll be trivial for the Paludis and pkgcore guys to
> > make this work since they already support USE flag depends.
>
> I would like the portage devs to comment upon which of the following
> features they think could easily be implemented before portage 2.2
> goes stable. There's still some time since it hasn't left
> package.mask yet, so I'd rather they exclude the features that will
> take too long to implement than anybody else doing that...

Well, actually I would rather not add any new features between pre8 and
rc1 to not further delay 2.2. And generally I'm also not in favor of
adding new features during the rc phase as it's there to eliminate
remaining bugs and for refinement of existing features, not to add new
unknowns.

> Already implemented:
> - Use dependencies, it's not clear to me whether we all agree
> entirely upon the syntax yet though (bugs #2272 and #174406)
>
> Things I believe should be trivial to implement:
> - Custom output names in SRC_URI, also called arrows (bug #177863)

This I'd definitely delay as it probably affects a number of things.

> - Guarantee trailing slashes (bug #174408)

Mostly a matter of finding the relevant spots, the actual work to
implement it would be trivial. Could be considered as bugfix.

> - Limit values in $USE (bug #176467)

Also requires little actual work, question is only if this should be
enabled for EAPI=0/1 as well, and how it relates to USE_EXPAND and ARCH.
If it should be done for existing EAPIs as well could be considered as
bugfix.

> - doins support for symlinks (bug #179932)

If someone implements it it can be included (do you want an EAPI bump
for that?)

> - Enable FEATURES=test by default (bug #184812)

Only if >99% of the stable and ~arch tree and all potential "system"
packages build with it (IOW: no)

> - GLEP 42 - news items

Already implemented.

> Bigger features I'm interested in:
> - Making do* die on failure by default (without changing their
> behaviour for previous eapis). Possibly adding either nonfatal or
> try_do* for cases where this isn't desired. (bug #138792)
> - More phases
> - src_prepare, for applying patches and running autotools etc.
> - src_configure, for running configure scripts (bug #197859)
> - pkg_pretend (bug #177860 - could also be used to fix bug #75936)
> - maint_*, it's not clear to me if this has been fleshed out in
> sufficient detail yet (bug #185567)

Unlikely for 2.2.

> - default_*, allows an ebuild to redefine phases to add more
> functionality and then call default_$phase. Currently the default
> phases are lost when redefining the phases.

Should be trivial to implement off-hand (just converting the existing
defaults to wrappers)

> - default for src_install (bug #33544)

Should also not be terribly difficult, though I'd rather wait until
after 2.2 final.

> - Ranged dependencies (bug #4315)

Unlikely for 2.2.

> Of course I'd like GLEPs 54 and 55 too but since the council still
> hasn't made a decision about them I'll leave them out..

Well, I already said everything about those during the first discussion
round and the relevant council meeting.

Marius

--
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.
 
Old 06-10-2008, 11:42 PM
Bo Ørsted Andresen
 
Default EAPI-2 - Let's get it started

On Wednesday 11 June 2008 01:03:47 Marius Mauch wrote:
> > I would like the portage devs to comment upon which of the following
> > features they think could easily be implemented before portage 2.2
> > goes stable. There's still some time since it hasn't left
> > package.mask yet, so I'd rather they exclude the features that will
> > take too long to implement than anybody else doing that...
>
> Well, actually I would rather not add any new features between pre8 and
> rc1 to not further delay 2.2. And generally I'm also not in favor of
> adding new features during the rc phase as it's there to eliminate
> remaining bugs and for refinement of existing features, not to add new
> unknowns.

Ok.

> > Things I believe should be trivial to implement:
> > - Custom output names in SRC_URI, also called arrows (bug #177863)
>
> This I'd definitely delay as it probably affects a number of things.

Such as?

> > - Limit values in $USE (bug #176467)
>
> Also requires little actual work, question is only if this should be
> enabled for EAPI=0/1 as well, and how it relates to USE_EXPAND and ARCH.
> If it should be done for existing EAPIs as well could be considered as
> bugfix.
>
> > - doins support for symlinks (bug #179932)
>
> If someone implements it it can be included (do you want an EAPI bump
> for that?)

Listed those here because they block the EAPI tracker bug.

> > - Enable FEATURES=test by default (bug #184812)
>
> Only if >99% of the stable and ~arch tree and all potential "system"
> packages build with it (IOW: no)

Err.. Maybe this could have been phrased better but then I did expect you
would look at the bug before commenting. The idea is to enable tests by
default in EAPI 2 and beyond and let them stay off by default in EAPI 0 and
1. This way devs who want to use EAPI 2 will either have to fix their tests
or RESTRICT them. Doing it this way avoids the issue of having to fix the
whole tree all at once. Users can still choose not to go with the default.

> > - GLEP 42 - news items
>
> Already implemented.

And not really an EAPI issue. Hence I shouldn't have mentioned it here.

> > - default_*, allows an ebuild to redefine phases to add more
> > functionality and then call default_$phase. Currently the default
> > phases are lost when redefining the phases.
>
> Should be trivial to implement off-hand (just converting the existing
> defaults to wrappers)

So that's a candidate for EAPI 2.

> > - default for src_install (bug #33544)
>
> Should also not be terribly difficult, though I'd rather wait until
> after 2.2 final.

--
Bo Andresen
Gentoo KDE Dev
 
Old 06-11-2008, 12:11 AM
Brian Harring
 
Default EAPI-2 - Let's get it started

On Tue, Jun 10, 2008 at 05:54:49PM +0100, Richard Brown wrote:
> On Tue, Jun 10, 2008 at 17:39, Doug Goldstein <cardoe@gentoo.org> wrote:
> > At this point, we should really only discuss features that all 3 package
> > managers have implemented.
>
> I'm not sure that's a good idea, only two have implemented EAPI 1 so far.

3 have. If you're aware of a pkgcore issue, then kindly file a bug
rather then going for mocking on -dev.

Cheers.
~harring
 
Old 06-11-2008, 12:21 AM
Marius Mauch
 
Default EAPI-2 - Let's get it started

On Wed, 11 Jun 2008 01:42:34 +0200
Bo Ørsted Andresen <zlin@gentoo.org> wrote:

> > > Things I believe should be trivial to implement:
> > > - Custom output names in SRC_URI, also called arrows (bug #177863)
> >
> > This I'd definitely delay as it probably affects a number of things.
>
> Such as?

Anything that uses SRC_URI.

> > > - Enable FEATURES=test by default (bug #184812)
> >
> > Only if >99% of the stable and ~arch tree and all potential "system"
> > packages build with it (IOW: no)
>
> Err.. Maybe this could have been phrased better but then I did expect
> you would look at the bug before commenting. The idea is to enable
> tests by default in EAPI 2 and beyond and let them stay off by
> default in EAPI 0 and 1. This way devs who want to use EAPI 2 will
> either have to fix their tests or RESTRICT them. Doing it this way
> avoids the issue of having to fix the whole tree all at once. Users
> can still choose not to go with the default.

Which means it's no longer controlled by a single FEATURES flag,
FEATURES=test means always on, while FEATURES=-test (or missing) means
always off.
Means it's not a simple switch anymore, therefore unlikely for 2.2.

Marius

--
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.
 
Old 06-11-2008, 12:37 AM
Brian Harring
 
Default EAPI-2 - Let's get it started

On Wed, Jun 11, 2008 at 01:42:34AM +0200, Bo ??rsted Andresen wrote:
> On Wednesday 11 June 2008 01:03:47 Marius Mauch wrote:
> > > Things I believe should be trivial to implement:
> > > - Custom output names in SRC_URI, also called arrows (bug #177863)
> >
> > This I'd definitely delay as it probably affects a number of things.
>
> Such as?

mirror-dist, aka the GENTOO_MIRROR infrastructure.


> > > - Limit values in $USE (bug #176467)
> >
> > Also requires little actual work, question is only if this should be
> > enabled for EAPI=0/1 as well, and how it relates to USE_EXPAND and ARCH.

eapi2 only imo, further, seems daft to limit $USE namespace while
forcing all USE_EXPAND targets in.

Basically, IUSE should be extended to mark/state what USE_EXPAND
namespaces it cares about- for ARCH (and friends), I'd expect they're
pushed in regardless of IUSE.


> > > - Enable FEATURES=test by default (bug #184812)
> >
> > Only if >99% of the stable and ~arch tree and all potential "system"
> > packages build with it (IOW: no)
>
> Err.. Maybe this could have been phrased better but then I did expect you
> would look at the bug before commenting. The idea is to enable tests by
> default in EAPI 2 and beyond and let them stay off by default in EAPI 0 and
> 1. This way devs who want to use EAPI 2 will either have to fix their tests
> or RESTRICT them. Doing it this way avoids the issue of having to fix the
> whole tree all at once. Users can still choose not to go with the default.

This shouldn't be forced through by PM's, this should be forced
through by communal dev agreement; I'd suggest getting that before
trying to slide it into an eapi.

I'd prefer tests on, but I'm not convinced eapi level is the right
area- realistically, that seems repo specifics (due to repo quality
varying). Either way, discussion is needed- I really doubt devs are
going to be happy (let alone users if devs aren't careful) if they
suddenly are forced to cleanup upstreams tests now, rather then as
time permits.


> > > - default_*, allows an ebuild to redefine phases to add more
> > > functionality and then call default_$phase. Currently the default
> > > phases are lost when redefining the phases.
> >
> > Should be trivial to implement off-hand (just converting the existing
> > defaults to wrappers)
>
> So that's a candidate for EAPI 2.

base_* please, rather then default; precedent is already there via
base.eclass. Not a hard req however, just a suggestion.

~harring
 
Old 06-11-2008, 03:34 AM
Brian Harring
 
Default EAPI-2 - Let's get it started

On Tue, Jun 10, 2008 at 12:26:55PM -0400, Doug Goldstein wrote:
> Let's try to aim to do an EAPI=2 sometime soonish since Portage now has
> USE flag depends in version 2.2 which is looming on the horizon. It'd be
> nice to hit the ground running with supporting these. I know it'll be
> trivial for the Paludis and pkgcore guys to make this work since they
> already support USE flag depends.

The relevant bugs that should go into eapi2-

bug 211529 (econf == configure --disable-dependency-tracking
--enable-fast-install)
bug 205557 (export var/api indicating what sort of op this is-
replace, install, uninstall, for pkg_*)
bug 203891: STRIP_MASK; this would allow ebuilds to be fully unaware
of the strip implementation, although would require the var to be
in binpkg metadata (pkgcore specific request, since we allow
stripping of unstripped binpkgs)
bug 199722: use/useq; nail it down to one or the other imo.

Not bugged, but potentials for minor cleanup:
* drop AA (basically unused)
* drop RDEPEND=${RDEPEND-${DEPEND}}, unless there is a strong arg to
keep it (I recall a historical strong arg to punt it)
* identify any remaining portageq additions needed to allow
/var/db/pkg to change format

From the "proposed way back when but never got off the ground":
* USE mutually exclusive representation; fancy way of moving code like
use foon && use !blah && die "blah must be enabled if foon is enabled"
into a form that can be detected up front, instead of going 'boom' at
pkg_setup time. This was originally proposed to address USE
configurations states for php pkgs, quick look, it still could be
useful. Would be implemented via a new metadata key most likely.


Finally; it needs updating, but glep33
(http://glep.gentoo.org/glep-0033.html) I'd be interested in trying to
get into eapi2. Currently, all managers support some form of env
saving/restoration that the glep required, so that dependency is gone.

What remains is basically updating the glep (I can do so), council
agreement (presume non issue), and implementation- easy for pkgcore,
presumably easy enough for paludis, easy for portage (already asked
zac).

If glep33 went in, I'd suggest bug 197859: split
src_configure/src_compile . Without g33, holding off on
src_configure/src_compile would likely be wise since it introduces
some potentially nasty eapi related issues in eclasses.

Comments welcome.
~harring
 
Old 06-11-2008, 04:24 AM
Luca Barbato
 
Default EAPI-2 - Let's get it started

Bo Ørsted Andresen wrote:

- Enable FEATURES=test by default (bug #184812)

Only if >99% of the stable and ~arch tree and all potential "system"
packages build with it (IOW: no)


Err.. Maybe this could have been phrased better but then I did expect you
would look at the bug before commenting.


The bug itself should be phrased better.

The idea is to enable tests by
default in EAPI 2 and beyond and let them stay off by default in EAPI 0 and
1. This way devs who want to use EAPI 2 will either have to fix their tests
or RESTRICT them. Doing it this way avoids the issue of having to fix the
whole tree all at once. Users can still choose not to go with the default.


People will (and should) have -test in FEATURES anyway, good self-test
suites usually take more than twice the time to build and run, may have
additional dependencies that could take lots of time.


lu

--

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

--
gentoo-dev@lists.gentoo.org mailing list
 
Old 06-11-2008, 05:16 AM
Ryan Hill
 
Default EAPI-2 - Let's get it started

On Wed, 11 Jun 2008 01:42:34 +0200
Bo Ørsted Andresen <zlin@gentoo.org> wrote:
> Err.. Maybe this could have been phrased better but then I did expect
> you would look at the bug before commenting. The idea is to enable
> tests by default in EAPI 2 and beyond and let them stay off by
> default in EAPI 0 and 1. This way devs who want to use EAPI 2 will
> either have to fix their tests or RESTRICT them. Doing it this way
> avoids the issue of having to fix the whole tree all at once. Users
> can still choose not to go with the default.

if people are just going to RESTRICT tests when they fail (and they
will, because it's a hell of a lot easier than actually fixing them),
what's the point of having a testsuite at all? and once a testsuite is
restricted, it'll stay restricted even if upstream fixes the problem
because no one will bother checking. the time needed for
testsuites can be substantial. (auto{make,conf} can take half an hour
to run the tests on a fast machine (compared to the total compile
and install time of 10 seconds). the build time for gcc triples.) they
can pull in a large number of dependencies. etc, etc.

as i mentioned on the bug, i'd like to see something like
FEATURES=dev that would enable tests by default, turn on those QA
source code warnings, maybe some of the stuff from stricter, and other
things that our users don't really need but are important to us.

anyways, just my opinion.

> Users can still choose not to go with the default.

so can devs, and they outnumber us.


--
gcc-porting, by design, by neglect
treecleaner, for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
 

Thread Tools




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

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