Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, 11 Jun 2008 08:50:47 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote: > > And saving your ass when you're using a broken compiler that > > generates broken code that would force you to reinstall a working > > compiler by hand when the package manager gets h0rked. > > You (upstream) are supposed to test and early users are supposed to > check their bleeding edge stuff is working if they care enough. > People using released programs that are in stable shouldn't have to > do that. If everyone running stable used the same base system, tool chain and configuration you would be right. But every Gentoo system is different, so there's no common target to test on. And it's fairly well established that lots stable Gentoo users have broken toolchains... > If your code doesn't survive a gcc release usually it's the code > being wrong most of the times. If you have bad code, yes. If you have good code, instead it's usually gcc's fault. Things like gcc bug 31899 are common enough to be a nuisance. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 - Let's get it started
Ciaran McCreesh wrote: You assume that users have working, properly configured compilers. It's fairly well established that a lot of them don't, particularly on Gentoo. "if your code sucks isn't our fault." - gcc upstream -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
Ciaran McCreesh wrote: Sure it will. They won't be able to install their package without either passing src_test or restricting it. Developers *do* try to install things before committing, right? No, they also write the ebuilds using cat /dev/urandom through a perl regexp. But more importantly, it still means that people *know* that a failing src_test is to be investigated. Currently they instead have to guess whether it's a lazy developer issue or a genuine bug being shown. Not really. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
Ciaran McCreesh wrote: On Wed, 11 Jun 2008 07:53:21 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote: A whole bunch of science packages have upstreams that say "If you're building from source, run 'make check' and if it fails don't carry on". Their rationale behind that is that their code is severely broken, using experimental features from their language of choice or, simply, that they are paranoid and couldn't think better ways to annoy people? Their rationale being that compilers and users screw up, and that detecting a failure before deployment is important for people who care about what programs do. Simple example... Take people who use Roy's broken patches from bug 192403. If you build a program that uses C++ exception handling using such a compiler, it'll compile just fine and then do very weird things at runtime. Test suites catch this, and spare a lot of everyone's time. You are supposed to test proposed patches for opened bugs before deploying them in any way. Your "example", that btw is a quite low try to smear Roy, proves nothing. And saving your ass when you're using a broken compiler that generates broken code that would force you to reinstall a working compiler by hand when the package manager gets h0rked. You (upstream) are supposed to test and early users are supposed to check their bleeding edge stuff is working if they care enough. People using released programs that are in stable shouldn't have to do that. If your code doesn't survive a gcc release usually it's the code being wrong most of the times. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Kelly wrote: | Wrong. Thanks for that. I'm gonna assume you meant "I think you're wrong". | Sure, because of how the algorithm works, people could potentially do | both, but the GLEP makes it pretty clear that they shouldn't. It doesn't just say they shouldn't, it *says what happens if they do*: pkg-4.ebuild-2, EAPI="1" ~pre-source EAPI is 2, post-source EAPI is 1. EAPI 1 is used So to live up to the GLEP specification, package managers must source the ebuild to determine the correct EAPI. | Basically, you don't set the post-source EAPI. It is only supposed to | be used when the pre-source EAPI cannot be determined. If that's what was meant, the GLEP needs changing to say that. Something like: pkg-4.ebuild-2, EAPI="X" ~Pre-source EAPI is 2, post-source EAPI is X. In this instance the post-source EAPI is ignored, since a pre-source EAPI is set, so EAPI 2 is used. It's not a big deal, but it will need a change to the GLEP in its current form, if that's what's meant. Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkhPdRUACgkQu7rWomwgFXq1twCgqnFzBqQI8vl63faZ1cq27MF7 7ekAn0aA73nic1v/ovwAUuHsaL44MrTE =StC2 -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
On Wed, 11 Jun 2008 08:31:45 +0200 Thomas de Grenier de Latour <[EMAIL PROTECTED]> wrote: > On 2008/06/11, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > > You're missing the cases where the cache isn't usable. > > I was not talking about generating cache entries, and neither were > you. I've replied to you because you were suggesting that the "EAPI in > ebuilds contents" solution had extra cost when _using_ valid cache > entries (need to extract the EAPI from the ebuild before reading this > cache entry), which i think can be easily avoided. And it does, since EAPI has to be known to use the cache contents. The way it's handled currently is a hack that doesn't work with future EAPIs defining new metadata. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: GLEP 55
On 2008/06/11, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > You're missing the cases where the cache isn't usable. > I was not talking about generating cache entries, and neither were you. I've replied to you because you were suggesting that the "EAPI in ebuilds contents" solution had extra cost when _using_ valid cache entries (need to extract the EAPI from the ebuild before reading this cache entry), which i think can be easily avoided. On 2008/06/10, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > Currently we don't touch the ebuild's content *at all* for metadata > operations, except where there's no or stale metadata cache (which is > rare). We can get away with this currently because 0 and 1 have > identical cache layouts and PMS has some (necessary) weasel wording; > future EAPIs likely won't, so we're back to the chicken / egg problem. > > So... We either have the EAPI from the extension (which we already > have, since we have to read the dir to know what versions are > available), in which case we know how to read the metadata cache file. > Or we have to open up a file that would otherwise not be opened, just > to parse one line so we know how to read the cache file. -- TGL. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, 11 Jun 2008 08:02:48 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote: > > Had you bothered to write even trivial test suites for EAPI 1, > > you'd've found at least one major bug straight away. > > http://www.pkgcore.org/trac/pkgcore/newticket http://www.pkgcore.org/trac/pkgcore/ticket/197 -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, 11 Jun 2008 08:01:30 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > > On Wed, 11 Jun 2008 07:49:44 +0200 > > Alexis Ballier <[EMAIL PROTECTED]> wrote: > >> I thought tests were already supposed to pass whatever the EAPI is > >> and devs were supposed to run them... > > > > Supposedly. But in practice this isn't true, because far too many > > developers just don't care. > > and having it forced in the eapi won't change this. Sure it will. They won't be able to install their package without either passing src_test or restricting it. Developers *do* try to install things before committing, right? > > Enforcing src_test in a "you must explicitly say so if your > > package's test suites are expected to fail" way on an EAPI bump is > > a clean way of recovering from this. > > You are assuming that every package has a test (false), nobody will > have src_test dummified. Not at all. If upstream has no test suite, or developers choose to RESTRICT off test, it just means there's less QA being done for that package. But more importantly, it still means that people *know* that a failing src_test is to be investigated. Currently they instead have to guess whether it's a lazy developer issue or a genuine bug being shown. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 - Let's get it started
Ciaran McCreesh wrote: On Tue, 10 Jun 2008 17:11:23 -0700 Brian Harring <[EMAIL PROTECTED]> wrote: On Tue, Jun 10, 2008 at 05:54:49PM +0100, Richard Brown wrote: On Tue, Jun 10, 2008 at 17:39, Doug Goldstein <[EMAIL PROTECTED]> 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. Had you bothered to write even trivial test suites for EAPI 1, you'd've found at least one major bug straight away. http://www.pkgcore.org/trac/pkgcore/newticket lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, 11 Jun 2008 07:58:44 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > > Oh, so Gentoo has decided that basic QA is another 'poor programming > > practice' now? > > Having a good testsuite is part of the QA, having it not failing is > part of the QA, running it for supposedly tested code (thus having > those test passed already) every time isn't. You assume that users have working, properly configured compilers. It's fairly well established that a lot of them don't, particularly on Gentoo. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 - Let's get it started
Ciaran McCreesh wrote: On Wed, 11 Jun 2008 07:49:44 +0200 Alexis Ballier <[EMAIL PROTECTED]> wrote: I thought tests were already supposed to pass whatever the EAPI is and devs were supposed to run them... Supposedly. But in practice this isn't true, because far too many developers just don't care. and having it forced in the eapi won't change this. Enforcing src_test in a "you must explicitly say so if your package's test suites are expected to fail" way on an EAPI bump is a clean way of recovering from this. You are assuming that every package has a test (false), nobody will have src_test dummified. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, 11 Jun 2008 07:53:21 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote: > > A whole bunch of science packages have upstreams that say "If you're > > building from source, run 'make check' and if it fails don't carry > > on". > > Their rationale behind that is that their code is severely broken, > using experimental features from their language of choice or, simply, > that they are paranoid and couldn't think better ways to annoy people? Their rationale being that compilers and users screw up, and that detecting a failure before deployment is important for people who care about what programs do. Simple example... Take people who use Roy's broken patches from bug 192403. If you build a program that uses C++ exception handling using such a compiler, it'll compile just fine and then do very weird things at runtime. Test suites catch this, and spare a lot of everyone's time. > > For that matter, I'm strongly inclined to say that for Paludis > > too... > > Getting the build time from 30minutes to an hour or more? And saving your ass when you're using a broken compiler that generates broken code that would force you to reinstall a working compiler by hand when the package manager gets h0rked. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 - Let's get it started
Ciaran McCreesh wrote: Oh, so Gentoo has decided that basic QA is another 'poor programming practice' now? Having a good testsuite is part of the QA, having it not failing is part of the QA, running it for supposedly tested code (thus having those test passed already) every time isn't. People marking stuff ~ or stable should run the testsuite as a way to make sure the package is sound. Users shouldn't take this pain. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Tue, 10 Jun 2008 17:11:23 -0700 Brian Harring <[EMAIL PROTECTED]> wrote: > On Tue, Jun 10, 2008 at 05:54:49PM +0100, Richard Brown wrote: > > On Tue, Jun 10, 2008 at 17:39, Doug Goldstein <[EMAIL PROTECTED]> > > 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. Had you bothered to write even trivial test suites for EAPI 1, you'd've found at least one major bug straight away. Do everyone a favour and write yourself a load of unit tests for every bit of changed functionality in EAPI 1. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, 11 Jun 2008 07:49:44 +0200 Alexis Ballier <[EMAIL PROTECTED]> wrote: > I thought tests were already supposed to pass whatever the EAPI is and > devs were supposed to run them... Supposedly. But in practice this isn't true, because far too many developers just don't care. The whole mess started because src_test was introduced late on, but before EAPIs, so there was no incremental way of making tests usable. Enforcing src_test in a "you must explicitly say so if your package's test suites are expected to fail" way on an EAPI bump is a clean way of recovering from this. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 - Let's get it started
Ciaran McCreesh wrote:
On Wed, 11 Jun 2008 07:39:53 +0200
Rémi Cardona <[EMAIL PROTECTED]> wrote:
Ciaran McCreesh a écrit :
So how are we supposed to handle packages where upstream *require*
that anyone building from source runs 'make check'?
If it's required to get the final binaries, then it should be in
src_compile.
I don't know any package that does require such a thing, but IMHO it
should be a QA warning if a build system writes anything to ${D}
during src_test. (could sandbox be tweaked to do that?)
A whole bunch of science packages have upstreams that say "If you're
building from source, run 'make check' and if it fails don't carry on".
Their rationale behind that is that their code is severely broken, using
experimental features from their language of choice or, simply, that
they are paranoid and couldn't think better ways to annoy people?
For that matter, I'm strongly inclined to say that for Paludis too...
Getting the build time from 30minutes to an hour or more?
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, 11 Jun 2008 07:48:06 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > > On Wed, 11 Jun 2008 06:24:18 +0200 > > Luca Barbato <[EMAIL PROTECTED]> wrote: > >> 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. > > > > So how are we supposed to handle packages where upstream *require* > > that anyone building from source runs 'make check'? > > Spank them as we already do for people building their test as part of > the default target. Oh, so Gentoo has decided that basic QA is another 'poor programming practice' now? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] extending existing EAPI semantics
On Wed, 11 Jun 2008 07:46:39 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > > On Tue, 10 Jun 2008 22:33:41 -0700 > > Brian Harring <[EMAIL PROTECTED]> wrote: > >> Lay out how .006/.6 would work properly *per* eapi. As I clarified > >> in my last email, the master would vary dependant on the eapi- > >> which isn't valid unless you're retroactively overriding the > >> versioning rules of an eapi. > > > > "Must be a superset" being wrong does not mean "entirely arbitrary > > changes are OK" is right. > > You have actual usecases (eventually not thin air), which is your > counterproposal that works for them? Care to rephrase that in English? I'm not proposing anything, so I'm at a loss as to what you're going on about here. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 - Let's get it started
Patrick Lauer wrote: On Tuesday 10 June 2008 16:54:49 Richard Brown wrote: On Tue, Jun 10, 2008 at 17:39, Doug Goldstein <[EMAIL PROTECTED]> 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. Yes, but noone cares about Paludis. Now could you please do the rest of us a favour and keep the discussion focussed on improving technical details instead of random insults at others? Isn't that, in itself, an insult and you don't seem to have advanced the discussion at all. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, 11 Jun 2008 01:42:34 +0200 Bo Ørsted Andresen <[EMAIL PROTECTED]> 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 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. I thought tests were already supposed to pass whatever the EAPI is and devs were supposed to run them... Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 - Let's get it started
Ciaran McCreesh wrote: On Wed, 11 Jun 2008 06:24:18 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote: 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. So how are we supposed to handle packages where upstream *require* that anyone building from source runs 'make check'? Spank them as we already do for people building their test as part of the default target. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] extending existing EAPI semantics
Ciaran McCreesh wrote: On Tue, 10 Jun 2008 22:33:41 -0700 Brian Harring <[EMAIL PROTECTED]> wrote: Lay out how .006/.6 would work properly *per* eapi. As I clarified in my last email, the master would vary dependant on the eapi- which isn't valid unless you're retroactively overriding the versioning rules of an eapi. "Must be a superset" being wrong does not mean "entirely arbitrary changes are OK" is right. You have actual usecases (eventually not thin air), which is your counterproposal that works for them? lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, 11 Jun 2008 07:39:53 +0200
Rémi Cardona <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh a écrit :
> > So how are we supposed to handle packages where upstream *require*
> > that anyone building from source runs 'make check'?
>
> If it's required to get the final binaries, then it should be in
> src_compile.
>
> I don't know any package that does require such a thing, but IMHO it
> should be a QA warning if a build system writes anything to ${D}
> during src_test. (could sandbox be tweaked to do that?)
A whole bunch of science packages have upstreams that say "If you're
building from source, run 'make check' and if it fails don't carry on".
For that matter, I'm strongly inclined to say that for Paludis too...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] EAPI-2 - Let's get it started
Ciaran McCreesh a écrit :
So how are we supposed to handle packages where upstream *require* that
anyone building from source runs 'make check'?
If it's required to get the final binaries, then it should be in
src_compile.
I don't know any package that does require such a thing, but IMHO it
should be a QA warning if a build system writes anything to ${D} during
src_test. (could sandbox be tweaked to do that?)
Rémi
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] extending existing EAPI semantics
On Tue, 10 Jun 2008 22:33:41 -0700 Brian Harring <[EMAIL PROTECTED]> wrote: > Lay out how .006/.6 would work properly *per* eapi. As I clarified > in my last email, the master would vary dependant on the eapi- which > isn't valid unless you're retroactively overriding the versioning > rules of an eapi. "Must be a superset" being wrong does not mean "entirely arbitrary changes are OK" is right. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] extending existing EAPI semantics
Kindly respond to the rest of the email first of all... On Wed, Jun 11, 2008 at 06:22:31AM +0100, Ciaran McCreesh wrote: > On Tue, 10 Jun 2008 22:16:21 -0700 > Brian Harring <[EMAIL PROTECTED]> wrote: > > > Also, there is absolutely no reason for all future EAPIs to be a > > > superset of old eapis. > > > > .ebuild-$EAPI-n requires all *versioning rules* to be a superset of > > $EAPI=(n-1); if in doubt, re-read my example above. > > No it doesn't. It requires that versions be mappable to a single, > enumerable master version format. Big difference. You could quite > happily add -scm and remove _p in future EAPIs, for example. Lay out how .006/.6 would work properly *per* eapi. As I clarified in my last email, the master would vary dependant on the eapi- which isn't valid unless you're retroactively overriding the versioning rules of an eapi. ~harring pgpW4JMkxD1cz.pgp Description: PGP signature
[gentoo-dev] Re: EAPI-2 - Let's get it started
On Wed, 11 Jun 2008 06:19:16 +0100 Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > On Tue, 10 Jun 2008 23:16:04 -0600 > Ryan Hill <[EMAIL PROTECTED]> wrote: > > 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. > > You're assuming that developers are lazy, incompetent and don't care > about QA. Historically speaking, yes. Well, one and three at least. ;) > If this isn't the case, developers will instead fix or > remove individual test failures where reasonably possible, and will > unrestrict tests when doing version bumps. That would be awesome, and i'd love to be proven wrong. -- 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 signature.asc Description: PGP signature
Re: [gentoo-dev] extending existing EAPI semantics
On Tue, 10 Jun 2008 22:16:21 -0700 Brian Harring <[EMAIL PROTECTED]> wrote: > > Also, there is absolutely no reason for all future EAPIs to be a > > superset of old eapis. > > .ebuild-$EAPI-n requires all *versioning rules* to be a superset of > $EAPI=(n-1); if in doubt, re-read my example above. No it doesn't. It requires that versions be mappable to a single, enumerable master version format. Big difference. You could quite happily add -scm and remove _p in future EAPIs, for example. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, 11 Jun 2008 06:24:18 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote: > 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. So how are we supposed to handle packages where upstream *require* that anyone building from source runs 'make check'? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: EAPI-2 - Let's get it started
On Tue, 10 Jun 2008 23:16:04 -0600 Ryan Hill <[EMAIL PROTECTED]> wrote: > 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. You're assuming that developers are lazy, incompetent and don't care about QA. If this isn't the case, developers will instead fix or remove individual test failures where reasonably possible, and will unrestrict tests when doing version bumps. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: EAPI-2 - Let's get it started
On Wed, 11 Jun 2008 01:42:34 +0200
Bo Ørsted Andresen <[EMAIL PROTECTED]> 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
signature.asc
Description: PGP signature
Re: [gentoo-dev] extending existing EAPI semantics
You actually pretty much completely misinterpreted what I was saying, so inserting the example back into the email and trying again... On Wed, Jun 11, 2008 at 12:25:55AM -0400, Mike Kelly wrote: > Brian Harring wrote: > >One thing I'll note is that the .ebuild-$EAPI approach isn't the end > >all fix to versioning extensions that y'all represent it as. > >Essentially, what .ebuild-$EAPI allows is additions to version > >comparison rules, no subtractions. Each new $EAPI *must* be a > >superset of previous $EAPIs. > > >An example would be removal of float comparison rules; for > ><=eapi-1, .006 < .6; Now if eapi-2 stated .006 == .6, that > >literally means that the PM would have to maintain versioning rules > >per eapi level, meaning that for an eapi1 ebuild, what it would > >match would differ from eapi2. Aside from that being a > >cluster-fuck in the implementation, it's a cluster-fuck for the dev > >trying to visualize what the manager is actually up to. > > Uhh... no. Just like how older package managers which don't understand > how to read the EAPI from a filename suffix would basically ignore the > new ebuilds, any package manager that can, but doesn't recognize the > eapi of the new one, will just ignore it. It won't ever try to figure > out its version or anything, it'll just do nothing. Here's the scenario: 1) EAPI1 defines foo-0.006 < foo-0.6. 2) EAPI2 redefine it so that foo-0.006 == foo-0.6 3) pkg 'a' has one version- '0.006' 4) pkg b-1, EAPI=1; DEPEND='<=a-0.006' 5) pkg c-1, EAPI=2; DEPEND='>=a-0.6' Now, via EAPI1 definition, b-1 *must* match a-0.006; via EAPI2 definition, b-2 *must* match a-0.006 also. The only way the manager can properly support this request is via getting the EAPI from the pkg that specified that request. Literally, the ordering of matches would have to vary dependant upon the eapi of the pkg. This is a serious cluster fuck for any implementation, and it's a pretty nice gotcha for ebuild developers. The sane alternative here is that each successive EAPI release, specifically the versioning rules, must be a superset of existing. Via that you can induce a total ordering that works regardless of the EAPI level of the generating pkg. A scenario that is far more entertaining is how the manager is supposed to handle the following: 1) EAPI2 defines 1.0-scm > 1.0 2) pkg 'a' has one visible version; 1.0-scm 3) pkg b-1 EAPI=1, DEPEND='<=a-1' 4) pkg c-1 EAPI=2, DEPEND='a' What is the correct result here? Since b-1's versioning rules don't know a damn thing about -scm, should it even be possible for it to use that version? The only valid solution here (since EAPI1 does not know, nor specify the ordering of -scm) is to bail. If you're maintaing a total ordering (each EAPI a superset of the last for versioning rules), you *could* retroactively decide on that case. Either way, point is that .ebuild-$EAPI doesn't magically solve versioning changes. It hides away user visibility of it, but doesn't solve the real issue. > Also, there is absolutely no reason for all future EAPIs to be a > superset of old eapis. .ebuild-$EAPI-n requires all *versioning rules* to be a superset of $EAPI=(n-1); if in doubt, re-read my example above. Non versioning rules of $EAPI, no, no requirement to be supersets of proceeding- but versioning under .ebuild-$EAPI, yes, it's required. Cheers, ~harring pgpfpgcWqYDmG.pgp Description: PGP signature
Re: [gentoo-dev] extending existing EAPI semantics
Mike Kelly wrote: Brian Harring wrote: One thing I'll note is that the .ebuild-$EAPI approach isn't the end all fix to versioning extensions that y'all represent it as. Essentially, what .ebuild-$EAPI allows is additions to version comparison rules, no subtractions. Each new $EAPI *must* be a superset of previous $EAPIs. Uhh... no. Just like how older package managers which don't understand how to read the EAPI from a filename suffix would basically ignore the new ebuilds, any package manager that can, but doesn't recognize the eapi of the new one, will just ignore it. It won't ever try to figure out its version or anything, it'll just do nothing. Also, there is absolutely no reason for all future EAPIs to be a superset of old eapis. While paludis (and presumably pkgcore and portage, I'm not as familiar with their code) has implemented EAPI=1 as a few additions to EAPI=0, there is no reason that gentoo might not decide to have EAPI=9000 some day, complete with artificial intelligence that completely obsoletes USE flags, or some such thing (it's late, I know the analogy sucks). Assuming we won't move from flat file to db lu - thinking of a darker future. -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
On Wed, 11 Jun 2008 09:52:17 +0530 "Arun Raghavan" <[EMAIL PROTECTED]> wrote: > On Wed, Jun 11, 2008 at 8:44 AM, Ciaran McCreesh > <[EMAIL PROTECTED]> wrote: > [...] > >> Why would you need the EAPI before the time when you actually want > >> to interpret the contents? > > > > You need the EAPI before you use the metadata. But you don't need > > the ebuild to get the metadata in the common case. > > Does the cache format _really_ need to be extensible the extent that > we're jumping hoops to support arbitrary cache formats? The cache format needs to be able to have keys added and removed from it. But the cache format is largely irrelevant here. There aren't any non-trivial EAPI related problems introduced by cache that don't already exist without cache. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] extending existing EAPI semantics
Brian Harring wrote: One thing I'll note is that the .ebuild-$EAPI approach isn't the end all fix to versioning extensions that y'all represent it as. Essentially, what .ebuild-$EAPI allows is additions to version comparison rules, no subtractions. Each new $EAPI *must* be a superset of previous $EAPIs. Uhh... no. Just like how older package managers which don't understand how to read the EAPI from a filename suffix would basically ignore the new ebuilds, any package manager that can, but doesn't recognize the eapi of the new one, will just ignore it. It won't ever try to figure out its version or anything, it'll just do nothing. Also, there is absolutely no reason for all future EAPIs to be a superset of old eapis. While paludis (and presumably pkgcore and portage, I'm not as familiar with their code) has implemented EAPI=1 as a few additions to EAPI=0, there is no reason that gentoo might not decide to have EAPI=9000 some day, complete with artificial intelligence that completely obsoletes USE flags, or some such thing (it's late, I know the analogy sucks). -- Mike Kelly -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] 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
Re: [gentoo-dev] Re: GLEP 55
On Wed, Jun 11, 2008 at 8:44 AM, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: [...] >> Why would you need the EAPI before the time when you actually want to >> interpret the contents? > > You need the EAPI before you use the metadata. But you don't need the > ebuild to get the metadata in the common case. Does the cache format _really_ need to be extensible the extent that we're jumping hoops to support arbitrary cache formats? -- Arun Raghavan (http://nemesis.accosted.net) v2sw5Chw4+5ln4pr6$OFck2ma4+9u8w3+1!m?l7+9GSCKi056 e6+9i4b8/9HTAen4+5g4/8APa2Xs8r1/2p5-8 hackerkey.com -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] extending existing EAPI semantics
On Wed, Jun 11, 2008 at 04:38:01AM +0100, Ciaran McCreesh wrote: > On Tue, 10 Jun 2008 20:33:11 -0700 > Brian Harring <[EMAIL PROTECTED]> wrote: > > > > * doesn't address versioning changes. > > > > > > Or indeed any change where the ebuild can't be visible to older > > > package managers without breaking them. > > > > > > So basically it's not a solution at all. > > > > Name a scenario. > > You already named one, and tried to gloss it over as not being the > complete showstopper that it is. Not exactly a show stopper; unknown versions are by and large ignored due to paludis devs forcing it upon others. Ironic, that one. You're also ignoring is that unlike the .ebuild-$EAPI approach, this minor refinement leaves open options for replacement, and that this option actually is likely far more agreeable then the filename approach you've been trying to force since EAPI's inception (which thus far hasn't taken hold despite positively massive noise from you). One thing I'll note is that the .ebuild-$EAPI approach isn't the end all fix to versioning extensions that y'all represent it as. Essentially, what .ebuild-$EAPI allows is additions to version comparison rules, no subtractions. Each new $EAPI *must* be a superset of previous $EAPIs. An example would be removal of float comparison rules; for <=eapi-1, .006 < .6; Now if eapi-2 stated .006 == .6, that literally means that the PM would have to maintain versioning rules per eapi level, meaning that for an eapi1 ebuild, what it would match would differ from eapi2. Aside from that being a cluster-fuck in the implementation, it's a cluster-fuck for the dev trying to visualize what the manager is actually up to. Personally, that's a pretty nasty unstated gotcha. .ebuild-$EAPI isn't the end all essentially, it has flaws just the same as other solutions. Marius/genone has advocated it in the past, and frankly I tend to agree at this point- versioning rules are a repo level property by and large, and the appropriate place to control that is at the repo level. So... someone other then ciaran have a comment? We already know ciarans views (hard not to when he has 2x greater posting ratio then any other person)... ~harring pgpQNmeUPmHge.pgp Description: PGP signature
Re: [gentoo-dev] extending existing EAPI semantics
On Tue, 10 Jun 2008 20:33:11 -0700 Brian Harring <[EMAIL PROTECTED]> wrote: > > If profile.bashrc is to be kept, it means massively reducing what > > can be done in there. > > Restraint in use of profile.bashrc is a per community QA measure, not > a format restriction- think through the other "this is better for QA" > things I've suggested PMS wise, you've responded in the same manner. Except that if profile.bashrc can tinker with package manager internals, it has to be done in such a way that it works with all package managers. So it has to be either Portage-specific or extremely constrained. > > > * doesn't address versioning changes. > > > > Or indeed any change where the ebuild can't be visible to older > > package managers without breaking them. > > > > So basically it's not a solution at all. > > Name a scenario. You already named one, and tried to gloss it over as not being the complete showstopper that it is. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] 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
pgpNQ16S5rI9j.pgp
Description: PGP signature
Re: [gentoo-dev] extending existing EAPI semantics
On Wed, Jun 11, 2008 at 04:20:04AM +0100, Ciaran McCreesh wrote: > On Tue, 10 Jun 2008 19:56:23 -0700 > Brian Harring <[EMAIL PROTECTED]> wrote: > > * easy to shoehorn in for any profile.bashrc compliant manager > > (portage/pkgcore); realize paludis is left out here (via it > > intentionally being left out of PMS atm by ciaran), but > > profile.bashrc *is* used by ebuild devs, thus it's a viable course (I > > don't see profile.bashrc ever going away basically). > > If profile.bashrc is to be kept, it means massively reducing what can > be done in there. Restraint in use of profile.bashrc is a per community QA measure, not a format restriction- think through the other "this is better for QA" things I've suggested PMS wise, you've responded in the same manner. > > * doesn't address versioning changes. > > Or indeed any change where the ebuild can't be visible to older package > managers without breaking them. > > So basically it's not a solution at all. Name a scenario. Note, if the scenario is "pm doesn't support eapi function, and doesn't support profile.bashrc", skip it, you're repeating what I already laid out (which results in visible bash complaints, but the manager still labeling the eapi inoperable). ~harring pgp7ybFpcdLqq.pgp Description: PGP signature
Re: [gentoo-dev] extending existing EAPI semantics
On Tue, 10 Jun 2008 19:56:23 -0700 Brian Harring <[EMAIL PROTECTED]> wrote: > * easy to shoehorn in for any profile.bashrc compliant manager > (portage/pkgcore); realize paludis is left out here (via it > intentionally being left out of PMS atm by ciaran), but > profile.bashrc *is* used by ebuild devs, thus it's a viable course (I > don't see profile.bashrc ever going away basically). If profile.bashrc is to be kept, it means massively reducing what can be done in there. > * doesn't address versioning changes. Or indeed any change where the ebuild can't be visible to older package managers without breaking them. So basically it's not a solution at all. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 55 - The Long Thread
On Tue, 10 Jun 2008 15:43:55 -0400 Doug Goldstein <[EMAIL PROTECTED]> wrote: > > The use cases are stated rather clearly in the GLEP, which you > > clearly didn't bother to read... > > > Concrete use cases instead of idealistic ones... What, new global scope functions is insufficiently concrete? New global scope functions to replace versionator with something on the package manager side. New global scope functions to allow per-cat/pkg eclasses. Take your pick. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: GLEP 55
On Tue, 10 Jun 2008 19:14:11 +0200 Olivier Galibert <[EMAIL PROTECTED]> wrote: > On Tue, Jun 10, 2008 at 03:02:28PM +0100, Ciaran McCreesh wrote: > > Except that currently, the ebuild file isn't opened for read. So > > it's not in memory at all. > > Why would you need the EAPI before the time when you actually want to > interpret the contents? You need the EAPI before you use the metadata. But you don't need the ebuild to get the metadata in the common case. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: GLEP 55
On Wed, 11 Jun 2008 01:36:01 +0200 Thomas de Grenier de Latour <[EMAIL PROTECTED]> wrote: > Or you apply to future EAPI's cache formats one of the solutions that > have been proposed for the ebuild side of the very same "chicken / egg > problem": for instance, you could use $EAPI as cache filename > extension. > > And that's it, you can get EAPI from the cache, hence no more extra > reading of ebuild files, and no more perfs issues. > > It sounds so simple, am I missing something obvious? You're missing the cases where the cache isn't usable. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] extending existing EAPI semantics
Bit curious what folks opinions are re: conversion of eapi
requirements into a function, instead of a var. Essentially,
currently-
"""
#my ebuild.
EAPI=1
inherit blah
DEPEND=monkey
funcs_and_such(){:;}
"""
pros:
* simple, and was enough to get EAPI off the ground w/out massive
fighting (at least not WW3 level fighting)
* works fine for metadata key level changes, function changes, etc.
I'm aware folks have stated "if DEPENDS changes, it won't be able to
handle it"- they're frankly wrong, they're confusing that post
sourcing EAPI is checked, *then* if EAPI is supported the metadata is
handled, else the manager is signaled that an unknown eapi was
encountered (essentially). Continuing...
cons:
* EAPI var must be set effectively before any invocations occur.
* global scope invocations (inherit) must be eapi aware;
* future additions to global scope invocations (say elib) will result
in an error spat by bash ("elib wasn't found").
* bash specific (which personally is fine to me, an ebuild is bash).
* doesn't address versioning changes.
Converting it into
"""
#my ebuild.
eapi 1
inherit blah
DEPEND=monkey
funcs_and_such(){:;}
"""
with eapi effectively being
eapi() {
if [ "$1" == 1 ] || [ "$1" == 0 ];
return # we know this eapi, can handle it
fi
die "unsupported eapi $1"
}
pros:
* same benefits as preexisting var approach.
* via conversion to invocation instead of var setting (which is
untrappable), it's possible to bail the rest of the sourcing, thus
preventing any error msgs for unknown global invocations (elib fex).
* easy to shoehorn in for any profile.bashrc compliant manager
(portage/pkgcore); realize paludis is left out here (via it
intentionally being left out of PMS atm by ciaran), but
profile.bashrc *is* used by ebuild devs, thus it's a viable course (I
don't see profile.bashrc ever going away basically).
cons:
* must be the first invocation.
* bash specific (again, ebuild is bash, new format can do things
w/out having to worry about backwards compatibility).
* doesn't address versioning changes.
Basically, the proposal is an minor tweak of existing support- it has
the benefit of avoiding the filename complaints from folks and
addressing the usual "global scope invocation will breakzor in later
versions" complaint from paludis folk.
It doesn't particularly provide for people shoving new versioning
components in, but frankly that's fine due to the mess having
versioning rules bound to EAPI would entail.
After comments from folks, although if a responder is going to state
"filename is better!" skip it please, I already pointed out the diffs
(meaning bluntly, kindly skip repeating what has already been said).
Cheers
~harring
pgpsalJ0dB2AH.pgp
Description: PGP signature
[gentoo-dev] Re: GLEP 55
Bernd Steinhauser <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Tue, 10 Jun 2008 05:46:47 +0200: > No, not really. If you have .txt, .txt-2, .text or .footext in a dir, > you would still realize, that those should be text files. The first three, yes, by long tradition, footext, not necessarily, as it's too ambiguous. Just like the penisland dot com domain, which is read as pen-island and sells pens, BTW (at least last time I looked, after it came up as an example in a discussion similar to this), is that foo-text or foot-ext (the way I would read it by default) or foote-XT or...? -- 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@lists.gentoo.org mailing list
Re: [gentoo-dev] 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 pgpqjkozdm18K.pgp Description: PGP signature
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, 11 Jun 2008 01:42:34 +0200 Bo Ørsted Andresen <[EMAIL PROTECTED]> 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. signature.asc Description: PGP signature
[gentoo-dev] Re: A few questions to our nominees
"=?UTF-8?Q?Piotr_Jaroszy=C5=84ski?=" <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Mon, 09 Jun 2008 22:13:20 +0200: > What's the point of sourcing an ebuild that cannot be used anyway? As currently seen in portage at least... a PM can be aware of and source an EAPI it can't use, but with the sourcing, can at least print a message to the effect "You must have a PM that supports EAPI-X in ordered to merge this package." If the ebuild can't be sourced, then ignoring it altogether is the safest alternative -- and what portage would do with anything other than .ebuild. It can't print a message giving the EAPI that must be supported, because it can't get that info, it being in the content that can't be sourced. With major-suffix minor-source, once the major-suffix rules were laid out, it would be possible to print support messages for minor (within the same major), as we do now, and provided the suffix rules were specific enough, for cross-major (only) as well, but not cross-major minor. IOW, the PM could print EAPI minor-1 (major being zero) messages as portage does now, and be made to print major-1 messages, but since it couldn't source, it couldn't get to the detail of major-1.minor-x, except after upgrade to a version that handled major-1, after which minor-x would either be supported or a new message could be printed prompting further upgrade/sidegrade/downgrade within the major support, to support the correct minor, as the case may be. -- 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@lists.gentoo.org mailing list
Re: [gentoo-dev] 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 <[EMAIL PROTECTED]> 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 pgpqqaXG5exBg.pgp Description: PGP signature
Re: [gentoo-dev] 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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: GLEP 55
On 2008/06/10, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > Currently we don't touch the ebuild's content *at all* for metadata > operations, except where there's no or stale metadata cache (which is > rare). We can get away with this currently because 0 and 1 have > identical cache layouts and PMS has some (necessary) weasel wording; > future EAPIs likely won't, so we're back to the chicken / egg problem. > > So... We either have the EAPI from the extension (which we already > have, since we have to read the dir to know what versions are > available), in which case we know how to read the metadata cache file. > Or we have to open up a file that would otherwise not be opened, just > to parse one line so we know how to read the cache file. Or you apply to future EAPI's cache formats one of the solutions that have been proposed for the ebuild side of the very same "chicken / egg problem": for instance, you could use $EAPI as cache filename extension. And that's it, you can get EAPI from the cache, hence no more extra reading of ebuild files, and no more perfs issues. It sounds so simple, am I missing something obvious? -- TGL. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
Richard Freeman wrote:
> On the other hand, this is a big change from the present, and I'm not
> convinced that it will actually be a big improvement over some of the
> other EAPI ideas being floated around. However, it is a
> potentially-neat idea...
Rich, interesting thoughts! But yeah, I agree that for now that is a lot.
My idea for the "#!" thing was much smaller-scale and is a way to add simple
syntax to allow declaration of the EAPI in the file with no sourcing and no
filename extension mangling (plus, no pre-source/post-source issues):
Just have one "shebang-like" line in the header before any real bash code
("#!EAPI=3", "#EAPI=3", or whatever is agreed-upon). This is out-of-band meta
info, so it's OK that it's in a "comment". It's ignored by bash, but it can be
read trivially without sourcing. To accelerate things for the tree (I've seen
others mention this idea too), store the EAPI in the portage cache when it is
generated.
-Joe
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, 11 Jun 2008 00:11:32 +0200 Bo Ørsted Andresen <[EMAIL PROTECTED]> 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. signature.asc Description: PGP signature
Re: [gentoo-dev] Re: GLEP 55
Santiago M. Mola wrote: On Tue, Jun 10, 2008 at 10:20 PM, Federico Ferri <[EMAIL PROTECTED]> wrote: The so-called shebang; very good in my opinion! Works very well for true shell scripts. why it can't work for ebuilds? This option was already discussed when GLEP 55 was proposed, and in my opinion it's totally discarded. The concept of shebang doesn't apply here at all. Plus /usr/bin/ebuild is a binary provided by portage which has nothing to do with the process of sourcing ebuilds nor even with the internals of portage (not to speak of other package managers). I had thought of this option as well - I agree that it has a lot of issues. I agree that ebuild wouldn't be the right tool, but in the right framework I could see how something like this might work. Here is how a portage tree might be handled by a future package manager that uses shebangs to implement any number of EAPIs that have almost no restrictions on file contents other than the shebang: When new "ebuilds" are synced into the repository, they are executed. If the interpreter doesn't exist, then it is an unsupported EAPI and the failure is silently ignored (or logged or whatever). If the interpreter does exist it will interpret the file properly - perhaps using a EAPI command-line option from the shebang line or whatever is appropriate for that EAPI which the interpreter obviously understands. If the interpreter determines that the file uses an EAPI it doesn't know, it aborts execution and skips the package. That makes the scheme always backwards compatible (well, at least until the switch to this approach - current package managers wouldn't be compatible). When the new ebuild is executed, it will call appropriate functions to register itself into the local repository. That registration might include callbacks of some kind or whatever - the whole way the ebuild works could vary by EAPI - since the interpreter used by the EAPI could change. The only restriction for compatibility is a standard shebang line. Each ebuild would only be executed upon a change when it is synced, so the overhead isn't huge. At that point all the data is stored in a local cache and the ebuilds themselves don't get touched until they are installed. Installation will work in an EAPI-dependent way - perhaps by executing the ebuild with a particular parameter or environment setting or whatever. The package manager will know since it has already been established that this is a supported EAPI by the fact that the ebuild got processed when it was synced in. This kind of system also makes it easy to support some scenarios that are currently hard: 1. Download a random ebuild off the internet and want to add it to your repository? Rather than having to put it in a local portage tree you could just execute it from anywhere and it would register itself in its present location - and act like any other package in the tree. 2. No need for utilities like ebuild to manipulate the install process - instead just execute the ebuild with the appropriate parameters or whatever to get it to do the install process. On the other hand, this is a big change from the present, and I'm not convinced that it will actually be a big improvement over some of the other EAPI ideas being floated around. However, it is a potentially-neat idea... -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
Mike Auty wrote:
The speed issues aren't really a concern, since the GLEP suggests that
the ebuild must be sourced anyway. The GLEP allows for a .ebuild-2 file
to contain EAPI="1".
Wrong. From the GLEP: "note that one should *never* explicitly set both
EAPIs to different values."
Basically, you don't set the post-source EAPI. It is only supposed to be
used when the pre-source EAPI cannot be determined. This is entirely for
backwards compatability with EAPI={0,1}. Once people start using
suffixed EAPIs, EAPI should not (probably "must not") be set in the
ebuild. Sure, because of how the algorithm works, people could
potentially do both, but the GLEP makes it pretty clear that they shouldn't.
--
Mike Kelly
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
On Tue, Jun 10, 2008 at 10:20 PM, Federico Ferri <[EMAIL PROTECTED]> wrote: > > The so-called shebang; very good in my opinion! > > Works very well for true shell scripts. why it can't work for ebuilds? This option was already discussed when GLEP 55 was proposed, and in my opinion it's totally discarded. The concept of shebang doesn't apply here at all. Plus /usr/bin/ebuild is a binary provided by portage which has nothing to do with the process of sourcing ebuilds nor even with the internals of portage (not to speak of other package managers). Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] 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 signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-user] dspam useflags improvement (was "tuning ./configure parameters via emerge")
Enrico Weigelt <[EMAIL PROTECTED]> a écrit:
> which package and which options are you exactly going to change ?
>
> IMHO, it's wise to improve the ebuild and perhaps add some useflag.
I agree. It seems that current useflags doesn't permit enough tuning.
Today, I need to use $EXTRA_ECONF with some packages.
For example, emerge dspam package to make it run with qmail doesn't
work. Here is what the dspam manual says:
-BEGIN--/usr/share/doc/dspam-3.8.0-r11/doc/qmair.txt.bz2--
USER-LEVEL INTEGRATION
If you are only configuring dspam for a small percentage of your users,
this is the best method. Configure dspam to use a standalone local
delivery agent like safecat (if you already use procmail or maildrop as
an LDA, you should call dspam from those tools directly).
First, create a small script called maildir_mod in /usr/local/bin...
#!/bin/sh
VPOPDOMAINS="/home/vpopmail/domains"
if [[ "$2" = "-d" ]]; then
user=`eval echo $3 | cut -f 1 -d "@"`
domain=`eval echo $3 | cut -f 2 -d "@"`
cd $VPOPDOMAINS/"$domain"/"$user"
fi
/usr/local/bin/safecat "$1"/tmp "$1"/new 1>/dev/null
NOTE: Be sure to configure VPOPDOMAINS to point to the path for your
virtual domain directories
Now configure DSPAM:
./configure \
--with-dspam-owner=vpopmail \
--with-dspam-group=vchkpw \
--with-delivery-agent="/usr/local/bin/maildir_mod Maildir -d %u" \
# Your arguments
Next, create a .qmail file in the directory for the user with a line to
call dspam, like this:
| /usr/local/bin/dspam --deliver=innocent --user [EMAIL PROTECTED]
The two environment variables $EXT and $USER are created by the
qmail-local program which begins the local delivery process.
-END/usr/share/doc/dspam-3.8.0-r11/doc/qmair.txt.bz2--
Here is the ebuild content:
-BEGIN--/usr/portage/mail-filter/dspam/dspam-3.8.0-r11.ebuild-
econf --with-storage-driver=${STORAGE} \
--with-dspam-home="${DSPAM_HOMEDIR}" \
--sysconfdir="${DSPAM_CONFDIR}" \
$(use_enable daemon) \
$(use_enable ldap) \
$(use_enable clamav) \
$(use_enable large-domain large-scale) \
$(use_enable !large-domain domain-scale) \
$(use_enable syslog) \
$(use_enable debug) \
$(use_enable debug bnr-debug) \
$(use_enable debug verbose-debug) \
--enable-long-usernames \
--with-dspam-group=dspam \
--with-dspam-home-group=dspam \
--with-dspam-mode=${DSPAM_MODE} \
--with-logdir="${DSPAM_LOGDIR}" \
${myconf} || die "econf failed"
-END/usr/portage/mail-filter/dspam/dspam-3.8.0-r11.ebuild-
I run ('\' end-line char added in this mail only):
prompt> EXTRA_ECONF="--with-dspam-owner=vpopmail \
--with-dspam-group=vchkpw \
--with-delivery-agent=\"/usr/local/bin/maildir_mod Maildir \-d %u\"" \
emerge -v dspam
The compilation failed. I think I will make a bug report...
Nevertheless, I guess dspam and qmail integration can be done on
various ways and dspam can work with a lot of other MTA (you can see
/usr/share/doc/dspam-3.8.0-r11/doc/).
In this context, maintain this package (dspam) with useflags fair
system only would be a lot of work.
Having EXTRA_ECONF is enough (but should be probably more documented).
If dspam default ebuild could just compile with extra-parameters, it
would be great.
I hope I didn't missed something.
X-post + Fu2
--
Nicolas Sebrecht
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Freedesktop utils in ebuild
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 René 'Necoro' Neumann schrieb: > Hi list, > > I'm currently trying to update an ebuild (x11-misc/zim) to a new version. > The old one uses a patch to disable running "update-desktop-database" and > instead using the fdo-mime_desktop_database_update function. > > Now - the new ebuild also wants to call: > > - update-mime-database --> disable and use fdo-mime_mime_database_update ? > - xdg-icon-resource install --> let it run? - or disable it (and replace it > by what)? > > Would be glad, if someone could clarify the use here :) > > - Necoro > Ping? - Anyone? Regards, Necoro -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhO8b0ACgkQ4UOg/zhYFuBFSQCfXwsTyG+wgmwFRZeYDTYYu9IS 6FwAn0Vde7NSQkehB4T0BHymKGeC4b27 =SAW7 -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
Joe Peterson ha scritto:
It was mentioned that "comments are to be ignored", but you point out a
perfect and very fundamental example of where this is not true:
#!/usr/bin/env bash
Putting another line close to this one with:
#EAPI=42
or
#!EAPI=42
if you like (conforms more to the shell script specifier), is not too
muchh of a stretch.
The so-called shebang; very good in my opinion!
Works very well for true shell scripts. why it can't work for ebuilds?
First, I think of two alternatives:
1) the interpreter is the EAPI (with /usr/bin/ebuild being EAPI=0)
this will be the first line of a EAPI=0 ebuild:
#!/usr/bin/ebuild
this will be a EAPI=paludis ebuild:
#!/usr/bin/ebuild-paludis
apparently it's the same mechanism the shell uses to execute a shell
script, except for the fact that:
* ebuild is not an executable file
* an external program is used to determine the EAPI (i.e.: extract the
shebang)
2) fixed interpreter name, use arguments for switching EAPIs
this is another option, wich carries itself a GREAT power of leaving an
open door when in the future will happen something similar to what we
have now, where switching the EAPI (or replace EAPI with something else)
is critical and breaks compatibility.
example - EAPI=0:
#!/usr/bin/ebuild
...
another eapi:
#!/usr/bin/ebuild -eapi paludis
This allows virtually unlimited cases similar to this; for example when
switching to , another switch will
be used:
#!/usr/bin/ebuild -eapi foo -fluffy bar
Advantages of both solutions:
* easy to parse
* doesn't break compatibility
What it does not address:
* doesn't break compatibility
In fact, it should break compatibility.
again I can think of two solutions:
1) change the ebuild extension to a different value, once and
(hopefully) forever, e.g. from .ebuild to .xbuild, and leave the minimal
set of .ebuild-s for the upgrade path
2) use two repositories: the legacy one, needed for the upgrade path,
and the shyny-new-repository with the new ebuilds format
best regards,
Federico Ferri
--
#include
main(){printf("%x",4275974592);}
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS d-(--) a- C++$ UL+++$ L+++$ E--- W++@ w--@
PE PGP+ R- tv-- DI++>+++ D++ h+
--END GEEK CODE BLOCK--
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Nominations for council
On Thu, 5 Jun 2008 22:41:40 +0300 Samuli Suominen <[EMAIL PROTECTED]> wrote: > Tue, 3 Jun 2008 05:52:35 + > Ferris McCormick <[EMAIL PROTECTED]> kirjoitti: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > > > I think nominations are open. I nominate > > Then I'd like to nominate (mostly same ones again) [..] > aballier Thanks, but I decline. Considering all the nominee, I think there are enough people probably more able than I am to run a council. My habit of not getting involved in endless discussions would have probably not helped to get elected anyway ;) Moreover, with all the recent threads here, I don't think I want to be in the group that will have to take the decisions. Regards, Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] 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 <[EMAIL PROTECTED]> 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
Re: [gentoo-dev] GLEP 55 - The Long Thread
Ciaran McCreesh wrote: On Tue, 10 Jun 2008 10:51:39 -0400 Doug Goldstein <[EMAIL PROTECTED]> wrote: I urge you all to sit down and hammer out real use case situations instead of the idealistic "foo/bar/baz" concepts. The use cases are stated rather clearly in the GLEP, which you clearly didn't bother to read... Concrete use cases instead of idealistic ones... -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Tue, Jun 10, 2008 at 11:04 PM, Fernando J. Pereda <[EMAIL PROTECTED]> wrote: > > On 10 Jun 2008, at 18:39, Doug Goldstein wrote: >> 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 :/ How about we define this as EAPI=0? =) Jokes aside, I agree with you. Features that all three package managers have already implemented (release or beta) are quite uninteresting. However, this will make for a more sane discussion, and will _actually_ result in an EAPI=2 getting approved, say, in the next Council meeting. I say this is better than a feature-complete EAPI=2 that stays on hold for a year because we can't collectively decide on it, results in PM-specific overlays, loud bitching about how nothing ever gets done, and results in overall wastage of energy. > > We might, however, only discuss features that all 3 package managers can > implement easily. I say this should be done in the context of EAPI=3 once we all agree on what EAPI=2 should contain (let's take it slow ;) If we start discussing EAPI=3 *now*, we _might_ get it out 6 months later[1] ;p 1. Sorry, that's how open source usually works :) -- ~Nirbheek Chauhan -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
On 10 Jun 2008, at 18:39, Doug Goldstein wrote: Nirbheek Chauhan wrote: On Tue, Jun 10, 2008 at 10:00 PM, Patrick Lauer <[EMAIL PROTECTED]> 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 -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
On 10 Jun 2008, at 19:06, Patrick Lauer wrote: On Tuesday 10 June 2008 16:54:49 Richard Brown wrote: On Tue, Jun 10, 2008 at 17:39, Doug Goldstein <[EMAIL PROTECTED]> 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. Yes, but noone cares about Paludis. Ah, Paludis does support EAPI-1 just fine. Thank you. - ferdy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
Olivier Galibert a écrit : On Tue, Jun 10, 2008 at 12:01:00PM +0200, Rémi Cardona wrote: Ciaran McCreesh a écrit : Kills the upgrade path completely. No good. Lemme sum this up in layman's terms : 1) EAPI _has_ to be known before sourcing an ebuild. There's no way to avoid that for various reasons, all 100% valid. "sourcing" != "reading the first line/n first lines/first block and grepping". IO-wise, it's the same, as most ebuilds fit inside a kernel memory page (ie, 4KB on most arches). So with a cold cache, the time required to actually run bash to source the ebuild won't matter much. But we're getting lost on this thread, let's let it cool off for a little while :) Cheers, Rémi -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
On Tue, Jun 10, 2008 at 03:02:28PM +0100, Ciaran McCreesh wrote: > Except that currently, the ebuild file isn't opened for read. So it's > not in memory at all. Why would you need the EAPI before the time when you actually want to interpret the contents? OG. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Tuesday 10 June 2008 16:54:49 Richard Brown wrote: > On Tue, Jun 10, 2008 at 17:39, Doug Goldstein <[EMAIL PROTECTED]> 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. > Yes, but noone cares about Paludis. Now could you please do the rest of us a favour and keep the discussion focussed on improving technical details instead of random insults at others? Thanks ... -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
On Tue, Jun 10, 2008 at 12:01:00PM +0200, Rémi Cardona wrote: > Ciaran McCreesh a écrit : > >Kills the upgrade path completely. No good. > > Lemme sum this up in layman's terms : > > 1) EAPI _has_ to be known before sourcing an ebuild. There's no way to > avoid that for various reasons, all 100% valid. "sourcing" != "reading the first line/n first lines/first block and grepping". OG. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Tue, Jun 10, 2008 at 17:39, Doug Goldstein <[EMAIL PROTECTED]> 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. -- Richard Brown -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Last rites: kde-base/ksync
# Tobias Heinlein <[EMAIL PROTECTED]> (10 Jun 2008) # Masked for removal on 20 Jun 2008. # Pulls in kdelibs of which all current versions are providing # the same functionality, thus already blocking ksync. kde-base/ksync -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
Nirbheek Chauhan wrote: On Tue, Jun 10, 2008 at 10:00 PM, Patrick Lauer <[EMAIL PROTECTED]> 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. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Tue, Jun 10, 2008 at 10:00 PM, Patrick Lauer <[EMAIL PROTECTED]> 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 :) -- ~Nirbheek Chauhan -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
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. So... let's get the party started. The question is then, what features do people want there? I've seen a few things mentioned, but I presume there are two restrictions - 1) feature needs to be reasonably useful to enough people 2) feature needs to be implementable in a short enough timeframe So EAPI 2 is not "everything shiny", but a small iterative improvement to EAPI 1. Suggest features then and let's discuss! -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] EAPI-2 - Let's get it started
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. So... let's get the party started. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Re: GLEP 55
Joe Peterson schrieb: Bernd Steinhauser wrote: And that is, what this is about, making EAPI bumps as less painful as possible. The filename is the easiest solution for that. In any design, there are "easy" short-cuts that can be taken. But sometimes these short-cuts break paradigms that are fundamental. If you wanted, you could throw a bunch of things into the filename and make it 255 characters long to avoid reading the file, but that clearly would be a pretty bad design. Yes, in principle you could do that, but in principle you could do the same with the first line in a file or whatever you are suggesting. I really fail to see the point, why it is so important, that the extension will still be .ebuild in the future. There is a lot of software, that keeps using the same filename for different versions of stuff and in many cases, that is a huge mess. Is the "huge mess" you are thinking of the basic reality that software of any reasonable complexity needs to deal with file formats evolving? If so, that is exactly why EAPIs now are being introduced. But almost all software deals with this transparently - no need to expose it to the user, and sticking the version in the filename is both fragile (renaming the file can alter it) and seems like a hack. Wow, altering the content of a file can alter it, too. What is the point there? BTW, so you are suggesting, that we shouldn't put the PV in the file name? We shouldn't put the revision in the file name? Hm, so in the future, there will be a "metadata.xml" file, that defines: - EAPI - PV - KEYWORDS - more stuff of the ebuild? Sounds complicated. I still haven't seen any good reasons against it. I realize that there are two camps of people here. One camp sees mangling the filename extension as an undesirable way to deal with this, and the other camp simply sees no problem with this. Seems to be like that. But I am really impress, how far some people go, to avoid renaming the file extension of a file. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: | No, it results in a new open() on a file that's elsewhere on disk, which | results in two new seeks. You get about fifty seeks per second. The speed issues aren't really a concern, since the GLEP suggests that the ebuild must be sourced anyway. The GLEP allows for a .ebuild-2 file to contain EAPI="1". This requires the package manager to source the ebuild to find out exactly what EAPI should be being used. The GLEP doesn't strictly outline what happens to a .ebuild-1 containing EAPI="2" for a PM that supports EAPI="2" (which needs to be addressed before the GLEP gets put into action). It does say a developer should not specify both a pre- and post- source EAPI, but the GLEP says that if both exist the post-source one is used. ~ That means all package managers would have to source the ebuilds. Personally, as a developer, I don't want to be messing around with yet more numbers in the ebuild filenames, and I think it looks ugly. Not great arguments, granted. It also feels like a bad idea to separate information required to process the contents of the file from the contents of the file itself. P/PN/PV variables are used in clearly defined locations of the file, and the script could run under a different name and version (as proved by every version bump around). The suggestion seems to be that an ebuild could not run under a different EAPI. In that case, the EAPI version should be embedded in the contents of the file. As people have pointed out though, there's no need to rush this decision. We're simply not going to achieve backwards compatibility forever (we haven't in the past), so why not choose a time period to allow for upgrades (6 months, a year?) and implement a new EAPI definition mechanism that's present in the file and offers a slightly better compromise between the various parties than the current suggestion? It will require a little more patience, but it offers time for a thought out and well designed choice. What's the rush? Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkhOpDEACgkQu7rWomwgFXoFvgCeMxSfRiQLEZr3QyT+Bx4b5aNe /9EAnicrcCQTXxsliAeM4mdisgjO7abg =tGD8 -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
On Tue, 10 Jun 2008 11:08:21 -0400 Richard Freeman <[EMAIL PROTECTED]> wrote: > I'm curious as to what operation in particular we're looking at. > Let's say I type in "paludis --sync": paludis --sync doesn't use metadata. > Next, suppose I type in "paludis -pi world": If it's straight after a --sync, then yes, some things are pre-loaded by rsync. Similarly, if it's straight after other operations, then yes, some things are pre-loaded. But we don't plan for "just the use cases that make our life easy". > Why wouldn't everything you need not already be in the cache? And if > something wasn't, then why is reading in the EAPI any slower than > reading in (R)DEPEND/KEYWORDS/IUSE/etc? Currently we don't touch the ebuild's content *at all* for metadata operations, except where there's no or stale metadata cache (which is rare). We can get away with this currently because 0 and 1 have identical cache layouts and PMS has some (necessary) weasel wording; future EAPIs likely won't, so we're back to the chicken / egg problem. So... We either have the EAPI from the extension (which we already have, since we have to read the dir to know what versions are available), in which case we know how to read the metadata cache file. Or we have to open up a file that would otherwise not be opened, just to parse one line so we know how to read the cache file. > What specific operation (from an end-user perspective) is improved by > putting EAPI in the filename? I'm not interested in theoretical > operations like "given a portage tree, find the EAPI of every file" - > users don't do those operations routinely in isolation, but as part > of larger operations where doing an open and a getline now just > speeds up the open and getline that would be executed 500 lines later > anyway. paludis -pi anything on a cold cache. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: GLEP 55
Ciaran McCreesh wrote: On Tue, 10 Jun 2008 19:40:22 +0530 "Arun Raghavan" <[EMAIL PROTECTED]> wrote: On Tue, Jun 10, 2008 at 7:32 PM, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: [...] I don't think that filename-vs-first-line is going to make a big difference in practical performance. It's about a factor of five difference in cold-cache resolution performance for Paludis. Could you please share more details on the experiment that showed this kind of performance degradation and the numbers, if possible? Shove an open and a getline in when doing what would otherwise be a successful cache read. It adds a couple of thousand new open()s on files that would otherwise be left alone, and changes the nice linear "slurp up things in this directory in order until we don't need anything else" pattern into "bounce backwards and forwards between lots of files in two different directories". On a cold cache, which is the most common use case, this is very very nasty. I'm curious as to what operation in particular we're looking at. Let's say I type in "paludis --sync": Obviously the first step is to rsync the portage tree. Then we find all modified files (already output by rsync) and update the caches. We already need to fully parse every file to create a dependency tree, so why is it slow to cache the EAPI for each file while we're at it? Next, suppose I type in "paludis -pi world": Why wouldn't everything you need not already be in the cache? And if something wasn't, then why is reading in the EAPI any slower than reading in (R)DEPEND/KEYWORDS/IUSE/etc? What specific operation (from an end-user perspective) is improved by putting EAPI in the filename? I'm not interested in theoretical operations like "given a portage tree, find the EAPI of every file" - users don't do those operations routinely in isolation, but as part of larger operations where doing an open and a getline now just speeds up the open and getline that would be executed 500 lines later anyway. Again, I'm not completely opposed to the idea of putting EAPI in the filename, but I'm not convinced that the arguments in favor of it are as clear-cut as some are suggesting. If everybody was open about the pros/cons of each solution and not suggesting that one solution is near-perfect and the others are total non-starters then this whole debate would probably be a whole lot less contentious. When people perceive that somebody isn't honest about the shortcomings of their own proposal then they're less likely to trust them - it is just a human thing... -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Re: GLEP 55
On Tue, 10 Jun 2008 09:02:29 -0600 Joe Peterson <[EMAIL PROTECTED]> wrote: > But almost all software deals with this transparently - no need to > expose it to the user, and sticking the version in the filename is > both fragile (renaming the file can alter it) and seems like a hack. The typical user does not deal with the ebuild files themselves, and if they are doing so it's because there's a deficiency in the tools available to them. Any user who *does* deal with ebuild files is doing something sufficiently advanced that they need to be aware of EAPIs anyway. As for fragile... You might as well say that sticking PN and PV in the file is fragile and a hack... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: GLEP 55
Bernd Steinhauser wrote: > And that is, what this is about, making EAPI bumps as less painful as > possible. The filename is the easiest solution for that. In any design, there are "easy" short-cuts that can be taken. But sometimes these short-cuts break paradigms that are fundamental. If you wanted, you could throw a bunch of things into the filename and make it 255 characters long to avoid reading the file, but that clearly would be a pretty bad design. > I really fail to see the point, why it is so important, that the > extension will still be .ebuild in the future. > > There is a lot of software, that keeps using the same filename for > different versions of stuff and in many cases, that is a huge mess. Is the "huge mess" you are thinking of the basic reality that software of any reasonable complexity needs to deal with file formats evolving? If so, that is exactly why EAPIs now are being introduced. But almost all software deals with this transparently - no need to expose it to the user, and sticking the version in the filename is both fragile (renaming the file can alter it) and seems like a hack. > I still haven't seen any good reasons against it. I realize that there are two camps of people here. One camp sees mangling the filename extension as an undesirable way to deal with this, and the other camp simply sees no problem with this. I want to point out, however, that the fact that you do not see the issue does not make the issue invalid. I am sure there are people who work at Apple who care nothing about the way an iPhone looks or feels and only care that it works correctly. If that person went to Steve Jobs and said, "Why are you spending so much money to make this thing look cool?", he would say that Apple is known for making cool things, and no one would buy something that works great but looks like a piece of junk. He'd be right. I realize this analogy is a bit of an exaggeration, but there is no reason we cannot make EAPIs work correctly and very efficiently (this is where technical innovation comes in), while also keeping the basic interface (and I include file name convention here) clean, standard, uncluttered, uncomplicated, and elegant. -Joe -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] GLEP 55 - The Long Thread
On Tue, 10 Jun 2008 10:51:39 -0400 Doug Goldstein <[EMAIL PROTECTED]> wrote: > I urge you all to sit down and hammer out real use case situations > instead of the idealistic "foo/bar/baz" concepts. The use cases are stated rather clearly in the GLEP, which you clearly didn't bother to read... -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] GLEP 55 - The Long Thread
Since there's so many places to comment and I have no intention of hitting all these areas, I'll just create a new thread. There's a lot to be said about being stuck in the "grand design mindset". I know many Gentoo, Portage, Exherbo, and Paludis developers are clearly coming to that point in their programming careers based on the comments on this thread and other threads. I would just like to caution everyone that they really need to get past this plateau in their programming careers and get on to the real mindset that matters in the future. The "use case" mindset. I urge you all to sit down and hammer out real use case situations instead of the idealistic "foo/bar/baz" concepts. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
On 10 Jun 2008, at 16:14, Ciaran McCreesh wrote: On Tue, 10 Jun 2008 19:38:52 +0530 "Arun Raghavan" <[EMAIL PROTECTED]> wrote: On Tue, Jun 10, 2008 at 7:30 PM, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: [...] - it doubles the number of file reads necessary during resolution. The first read will cause the file to be cached for subsequent reads anyway, so the performance hit boils down to an additional read() call (which will probably be buffered by your file I/O library anyway, so it's unlikely to even result in a context switch). And even without, it is well worth the lack of fugliness in the ebuild name. No, it results in a new open() on a file that's elsewhere on disk, which results in two new seeks. You get about fifty seeks per second. Plus path resolution, which isn't exactly free - ferdy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] GLEP 55 (was: A few questions to our nominees)
On Tue, 10 Jun 2008 15:36:58 +0100 Robert Bridge <[EMAIL PROTECTED]> wrote: > So relying on the file extension seems to be a recipe for > misunderstanding. Why limit the functionality of the package manager > to rely on the file names? How do you protect the package manager > from a malicious ebuild masquerading under the wrong EAPI? Relying on > the file name for information is the kind of design decision we laugh > at in Windows, so why adopt it here? There is no protection against malicious ebuilds. Malicious ebuilds already run code as root when you install them. Being able to get an ebuild run with the wrong EAPI is utterly irrelevant. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: GLEP 55
Ciaran McCreesh a écrit : No no. Doing the seek to open a file in a different directory and then seeking back to your original directory over and over when otherwise you'd be doing nice linear opens on adjacent inodes in a single directory is where the performance hit is. Paludis is pretty much seek bound in a lot of cases. Ok It's moving the relevant information further and further away from where it's supposed to be. It doubles the number of files a developer has to check in order to do simple ebuild maintenance. I said one file per package, not per ebuild. It only doubles the number of files if there's only one ebuild in a given package :) -- Rémi Cardona LRI, INRIA [EMAIL PROTECTED] [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] GLEP 55 (was: A few questions to our nominees)
On Tue, 10 Jun 2008 02:58:54 +0100 Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > > Well, in general, if you rely on extensions changing every time a > > program cannot deal with a new feature of a file format, it would be > > quite crazy. For example, if C programs had to start using ".c-2", > > ".c-3", etc., it would get ugly fast. > > Which is why programs that use any major C feature introduced since > 1980 use the extension '.cc' or '.cpp'. Except any program using .cc or .cpp for code is liable to break on gcc, as they are C++ file extensions, and to the best of my (admittedly limited knowledge) C and C++ are distinct languages... So relying on the file extension seems to be a recipe for misunderstanding. Why limit the functionality of the package manager to rely on the file names? How do you protect the package manager from a malicious ebuild masquerading under the wrong EAPI? Relying on the file name for information is the kind of design decision we laugh at in Windows, so why adopt it here? -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
On Tue, 10 Jun 2008 19:54:33 +0530 "Arun Raghavan" <[EMAIL PROTECTED]> wrote: > Well, most file systems have a local structure for this data (=> block > group), so it's not going to be a seek that's very far. Secondly, how > many ebuilds do you need to read directly to get this data in a > typical case? Isn't this what the metadata cache is for? It's a nice local structure when you're just using a) a nice, linear, readahead-friendly-ish slurp of the ebuild directory and b) a nice, linear slurp of files in the metadata cache, which is how things are now. When you move that to having to make alternating use of the metadata cache and the ebuild files, you're suddenly seeking backwards and forwards between two places over and over. > >> > - it heavily restricts future syntax and meaning of EAPIs > >> > >> Not by much. It's just a header. > > > > > > Do we want to keep the spec so wide open that we support any format > under the Sun that we fancy? Seems like overgeneralizing to me. We want to keep it open enough that we're not going to have to go through yet another backwards compatibility breaking change. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: GLEP 55
On Tue, 10 Jun 2008 16:11:49 +0200 Rémi Cardona <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh a écrit : > > The package manager does not currently source the whole thing with > > bash to get the EAPI, nor does it open the ebuild file at all for > > metadata. You're talking doubling the number of file operations > > here, and going from extremely good filesystem locality (which > > means very few seeks) to jumping backwards and forwards all over > > the place. > > Yeah, grepping through the ebuild is just bound to get a massive > performance hit, I don't have numbers but that just looks obvious. No no. Doing the seek to open a file in a different directory and then seeking back to your original directory over and over when otherwise you'd be doing nice linear opens on adjacent inodes in a single directory is where the performance hit is. Paludis is pretty much seek bound in a lot of cases. > Ciaran, what other pitfalls do you see for using one EAPI file per > package (except for the broken compatibility, I know it's a big one) ? It's moving the relevant information further and further away from where it's supposed to be. It doubles the number of files a developer has to check in order to do simple ebuild maintenance. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: GLEP 55
On Tue, 10 Jun 2008 19:40:22 +0530 "Arun Raghavan" <[EMAIL PROTECTED]> wrote: > On Tue, Jun 10, 2008 at 7:32 PM, Ciaran McCreesh > <[EMAIL PROTECTED]> wrote: > [...] > >> I don't think that filename-vs-first-line is going to make a big > >> difference in practical performance. > > > > It's about a factor of five difference in cold-cache resolution > > performance for Paludis. > > Could you please share more details on the experiment that showed this > kind of performance degradation and the numbers, if possible? Shove an open and a getline in when doing what would otherwise be a successful cache read. It adds a couple of thousand new open()s on files that would otherwise be left alone, and changes the nice linear "slurp up things in this directory in order until we don't need anything else" pattern into "bounce backwards and forwards between lots of files in two different directories". On a cold cache, which is the most common use case, this is very very nasty. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: GLEP 55
On Tue, Jun 10, 2008 at 7:44 PM, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: [...] >> The first read will cause the file to be cached for subsequent reads >> anyway, so the performance hit boils down to an additional read() call >> (which will probably be buffered by your file I/O library anyway, so >> it's unlikely to even result in a context switch). And even without, >> it is well worth the lack of fugliness in the ebuild name. > > No, it results in a new open() on a file that's elsewhere on disk, which > results in two new seeks. You get about fifty seeks per second. Well, most file systems have a local structure for this data (=> block group), so it's not going to be a seek that's very far. Secondly, how many ebuilds do you need to read directly to get this data in a typical case? Isn't this what the metadata cache is for? >> > - it heavily restricts future syntax and meaning of EAPIs >> >> Not by much. It's just a header. > > Do we want to keep the spec so wide open that we support any format under the Sun that we fancy? Seems like overgeneralizing to me. Regards, -- Arun Raghavan (http://nemesis.accosted.net) v2sw5Chw4+5ln4pr6$OFck2ma4+9u8w3+1!m?l7+9GSCKi056 e6+9i4b8/9HTAen4+5g4/8APa2Xs8r1/2p5-8 hackerkey.com -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Re: GLEP 55
Luca Barbato schrieb: Piotr Jaroszyński wrote: The simplest way is to change the syncpoint in the new package manager and leave the previous uri with a compatibility repo for the older ones. So we add a new repo each time a new EAPI comes out? Sounds like a big mess. It isn't you just keep 2 repos, one with the minimal eapi and the minimal set of ebuilds needed to upgrade, one with the latest and greatest. lu Then you could also just provide binaries... But lets face it, it slows down progress, because you will delay every change, because stuff like that you will only do if necessary. And it is still huge pain, from a users point of view, to upgrade stuff. And that is, what this is about, making EAPI bumps as less painful as possible. The filename is the easiest solution for that. I really fail to see the point, why it is so important, that the extension will still be .ebuild in the future. There is a lot of software, that keeps using the same filename for different versions of stuff and in many cases, that is a huge mess. I still haven't seen any good reasons against it. And btw, the KDE overlay users don't seem at all to be confused, because the packages are named .kdebuild-1 instead of .ebuild. Portage (and other tools) keeps happily ignoring them, like it should. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
Richard Freeman wrote: > Some object to parsing out the EAPI without sourcing the ebuild (only > bash can source bash). I disagree with this argument - every time you > run a shell script it is sourced by something other than bash - the > kernel has to figure out what script interpreter to use by parsing the > first line. There is no reason we can't use a magic number in the same > way with the EAPI. That isn't reason enough on its own to put the EAPI > in the filename, but it is a start. +1 It was mentioned that "comments are to be ignored", but you point out a perfect and very fundamental example of where this is not true: #!/usr/bin/env bash Putting another line close to this one with: #EAPI=42 or #!EAPI=42 if you like (conforms more to the shell script specifier), is not too muchh of a stretch. > Most software packages store version information internal to a file > format. I'm actually not aware of many that put it in the filename. Only a few, mainly Windows, I believe. Like .WSn (as pointed out on the Filename_extension wikipedia page). But oddballs like this suggest to me that a hack had to be done because the version could not be gleaned in a more subtle way from the file itself (e.g. MS Word does this transparently - all are ".doc"). -Joe -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
On Tue, 10 Jun 2008 19:38:52 +0530 "Arun Raghavan" <[EMAIL PROTECTED]> wrote: > On Tue, Jun 10, 2008 at 7:30 PM, Ciaran McCreesh > <[EMAIL PROTECTED]> wrote: > [...] > > - it doubles the number of file reads necessary during resolution. > > The first read will cause the file to be cached for subsequent reads > anyway, so the performance hit boils down to an additional read() call > (which will probably be buffered by your file I/O library anyway, so > it's unlikely to even result in a context switch). And even without, > it is well worth the lack of fugliness in the ebuild name. No, it results in a new open() on a file that's elsewhere on disk, which results in two new seeks. You get about fifty seeks per second. > > - it heavily restricts future syntax and meaning of EAPIs > > Not by much. It's just a header. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: GLEP 55
Ciaran McCreesh a écrit : The package manager does not currently source the whole thing with bash to get the EAPI, nor does it open the ebuild file at all for metadata. You're talking doubling the number of file operations here, and going from extremely good filesystem locality (which means very few seeks) to jumping backwards and forwards all over the place. Yeah, grepping through the ebuild is just bound to get a massive performance hit, I don't have numbers but that just looks obvious. Ciaran, what other pitfalls do you see for using one EAPI file per package (except for the broken compatibility, I know it's a big one) ? This is basic stuff you really need to know before you can comment sensibly on a discussion about package metadata. Then, thanks for explaining those things :) We are learning stuff as we go. -- Rémi Cardona LRI, INRIA [EMAIL PROTECTED] [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
Fernando J. Pereda wrote: On 10 Jun 2008, at 15:48, Luca Barbato wrote: Fernando J. Pereda wrote: No, it doesn't make parsing faster. *Had you bothered to profile any package manager you'd know that.* Do you have any number to share? What number are you interested in? Profiling numbers... lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
