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 bei
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 f
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 "th
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
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
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.
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 prev
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 bef
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
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
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
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
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 suppos
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
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
> > t
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 eap
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 a
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
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
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 vers
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.
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 bet
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 ha
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 va
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
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
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 st
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
> > >
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.
Peop
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,
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 c
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 s
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
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...
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
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
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 replie
-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
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 severe
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://de
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 suppos
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 importa
101 - 142 of 142 matches
Mail list logo
