-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
On Fri, 13 Apr 2007 14:21:16 +0200
Marius Mauch [EMAIL PROTECTED] wrote:
On Wed, 11 Apr 2007 15:41:01 +0100
Ciaran McCreesh [EMAIL PROTECTED] wrote:
* Phase changes: src_fetch - src_unpack - src_prepare -
src_configure -
On Fri, 09 Nov 2007 18:41:38 +0100
Marijn Schouten (hkBst) [EMAIL PROTECTED] wrote:
Use case one: package is completely unversioned upstream.
Have src_fetch add a version as appropriate to the downloaded/mirrored
version. This will work as change of upstream sources will be
detected by all the
Ciaran McCreesh wrote:
What, you're saying they all ship with test suites that exist but don't
work?
anything that takes more than 10m to test is broken from an user point
of view: you want the application, not having it tested.
I'd rather keep it in features since tests are _optional_, not
On Saturday 14 April 2007 18:14:48 Luca Barbato wrote:
Ciaran McCreesh wrote:
What, you're saying they all ship with test suites that exist but don't
work?
anything that takes more than 10m to test is broken from an user point
of view: you want the application,
Indeed, but speaking as a
Ciaran McCreesh wrote:
* src_test always called except if RESTRICT=test
I don't think this would fit into EAPI, to me it's an implementation
detail of the package manager, or why should the ebuild care about it?
It's the best way of ensuring that ebuilds have a working src_test.
Arch teams
not having it tested.
That all depends. If having it tested means that it _will_ work, I'd be
infavour of that.
Well, the problem is, that a working test suite does not guarantee a
working program, as well as a failing test suite doesn't necessarily
mean that the program is broken. This
Alec Warner napsal(a):
Any arch team that wants tests by default on their arch can just add
test to FEATURES in their arch profiles; magically the users running
that arch will get the tests run (with USE=test set) by default. Users
who don't want tests can always turn them off in make.conf.
Jakub Moc wrote:
Alec Warner napsal(a):
Any arch team that wants tests by default on their arch can just add
test to FEATURES in their arch profiles; magically the users running
that arch will get the tests run (with USE=test set) by default. Users
who don't want tests can always turn them
Jan Kundrát napsal(a):
Jakub Moc wrote:
Even such change would piss off users. Having *no* way to turn off
tests, uuuhhh please retire me *before* someone implements this, I'm not
going to waste my time on totally pointless bugs filed by furious users.
FEATURES=-test?
... wouldn't do
On Sat, 14 Apr 2007 02:44:31 -0700
Alec Warner [EMAIL PROTECTED] wrote:
Any arch team that wants tests by default on their arch can just add
test to FEATURES in their arch profiles; magically the users running
that arch will get the tests run (with USE=test set) by default.
Users who don't
Ciaran McCreesh wrote:
On Sat, 14 Apr 2007 02:44:31 -0700
Alec Warner [EMAIL PROTECTED] wrote:
Any arch team that wants tests by default on their arch can just add
test to FEATURES in their arch profiles; magically the users running
that arch will get the tests run (with USE=test set) by
On Sat, 14 Apr 2007 12:17:24 -0700
Alec Warner [EMAIL PROTECTED] wrote:
The whole argument against doing it the other way is that running
tests, outside of RESTRICT, has absolutly nothing to do with any kind
of api; which is why I'm against it. At that point arch teams would
essentially be
On Friday 13 April 2007, Luca Barbato wrote:
Ciaran McCreesh wrote:
* Remove automatic directory making for do*
Why?
hmm guess i should have read each item ... this is not something we want to do
and i dont recall anyone ever mentioning this change in behavior
-mike
pgpJHP7H0V6k1.pgp
On Wed, 11 Apr 2007 15:41:01 +0100
Ciaran McCreesh [EMAIL PROTECTED] wrote:
On Thu, 5 Apr 2007 15:11:47 -0700
Brian Harring [EMAIL PROTECTED] wrote:
Either way, EAPI=1 *should* have a bit more then just slot deps in my
opinion; very least it needs discussion to discern what folks want.
On Friday 13 April 2007, Marius Mauch wrote:
Ciaran McCreesh [EMAIL PROTECTED] wrote:
* src_test always called except if RESTRICT=test
I don't think this would fit into EAPI, to me it's an implementation
detail of the package manager, or why should the ebuild care about it?
hmm, i'd have to
On Fri, 13 Apr 2007 14:21:16 +0200
Marius Mauch [EMAIL PROTECTED] wrote:
On Wed, 11 Apr 2007 15:41:01 +0100
Ciaran McCreesh [EMAIL PROTECTED] wrote:
* Remove automatic directory making for do*
No
It masks all kinds of programming screwups. doblah should make a blah,
not make a blah and
On Friday 13 April 2007, Ciaran McCreesh wrote:
Marius Mauch [EMAIL PROTECTED] wrote:
Ciaran McCreesh [EMAIL PROTECTED] wrote:
* Remove automatic directory making for do*
No
It masks all kinds of programming screwups. doblah should make a blah,
not make a blah and possibly make a
On Fri, 13 Apr 2007 10:53:38 -0400
Mike Frysinger [EMAIL PROTECTED] wrote:
It masks all kinds of programming screwups. doblah should make a
blah, not make a blah and possibly make a directory.
name one
dosym's old behaviour prevented a broken Vim release (upstream screwed
up a Makefile
Mike Frysinger napsal(a):
* Remove automatic directory making for do*
No
It masks all kinds of programming screwups. doblah should make a blah,
not make a blah and possibly make a directory.
name one
you're proposing we suddenly bloat all of our src_install functions for no
gain at all
On Fri, 13 Apr 2007 17:36:33 +0200
Jakub Moc [EMAIL PROTECTED] wrote:
Mike Frysinger napsal(a):
* Remove automatic directory making for do*
No
It masks all kinds of programming screwups. doblah should make a
blah, not make a blah and possibly make a directory.
name one
you're
Ciaran McCreesh napsal(a):
What? No it wouldn't. It would ensure that bugs were caught during the
src_install phase rather than after a package has been installed.
What kind of bugs exactly? The ones *created* by this behavior change?
I'd rather not create such bugs for starters, because it's
On Fri, 13 Apr 2007 18:22:24 +0200
Jakub Moc [EMAIL PROTECTED] wrote:
Ciaran McCreesh napsal(a):
What? No it wouldn't. It would ensure that bugs were caught during
the src_install phase rather than after a package has been
installed.
What kind of bugs exactly? The ones *created* by this
On Fri, 13 Apr 2007 11:52:16 -0400
Mike Frysinger [EMAIL PROTECTED] wrote:
you're proposing we suddenly bloat all of our src_install
functions for no gain at all ... sounds like a no brainer to me
No, I'm proposing that functions not have strange side effects.
the behavior here is
Ciaran McCreesh napsal(a):
You're missing the point.
As of a year or so ago, dosym will succeed even if the dosym target
directory doesn't exist, and even if it means creating arbitrary
directories. Some other utilities, such as dohard for example, will
fail under otherwise identical
Jakub Moc kirjoitti:
Well of course it's the users who will see it, see above. It's not like
that we would have 100 volunteers around to drop everything they have in
their hands a go spend days on changing ebuilds that are not broken just
because of this idea.
We are talking about
On Fri, 13 Apr 2007 19:06:42 +0200
Jakub Moc [EMAIL PROTECTED] wrote:
Err, your suggestion was:
* Remove automatic directory making for do*
Because I was giving a one line summary, rather than a description of
the full change. The full description has been discussed elsewhere
several times.
On Fri, 13 Apr 2007 13:02:00 -0400
Mike Frysinger [EMAIL PROTECTED] wrote:
On Friday 13 April 2007, Ciaran McCreesh wrote:
These fail:
cp somefile dirdoesnotexist/
mv somefile dirdoesnotexist/
ln -s somefile dirdoesnotexist/
dohard somefile dirdoesnotexist/
mkdir
On Friday 13 April 2007, Ciaran McCreesh wrote:
Mike Frysinger [EMAIL PROTECTED] wrote:
On Friday 13 April 2007, Ciaran McCreesh wrote:
These fail:
cp somefile dirdoesnotexist/
mv somefile dirdoesnotexist/
ln -s somefile dirdoesnotexist/
dohard somefile dirdoesnotexist/
The arch teams have been pushing for this for a long time. They're
trying to get this enforced, but are having limited success because
there's no way for FEATURES=test to become widely used that won't
lead to broken user systems. Moving src_test to be always on in
future EAPIs is
The arch teams have been pushing for this for a long time. They're
trying to get this enforced, but are having limited success because
there's no way for FEATURES=test to become widely used that won't lead
to broken user systems. Moving src_test to be always on in future EAPIs
is an easy
On Fri, 13 Apr 2007 11:16:14 -0700
Joshua Jackson [EMAIL PROTECTED] wrote:
Erm, no I have not at all (speaking as a project lead for x86). Test
is not viable for a lot of reason as being on by default. One that I
can come up with off the top of my head is php. The test suite for it
makes test
On Friday 13 April 2007, Ciaran McCreesh wrote:
Joshua Jackson [EMAIL PROTECTED] wrote:
Erm, no I have not at all (speaking as a project lead for x86). Test
is not viable for a lot of reason as being on by default. One that I
can come up with off the top of my head is php. The test suite
Ciaran McCreesh wrote:
If a test suite isn't viable, the ebuild should be RESTRICTing test
anyway.
That means ALL the media applications, almost all the toolchain
applications, most languages and a couple of other items I don't touch.
I don't think it shoud be part of the spec even if you
On Fri, 13 Apr 2007 15:06:44 -0400
Mike Frysinger [EMAIL PROTECTED] wrote:
If a test suite isn't viable, the ebuild should be RESTRICTing test
anyway.
which doesnt apply here ... some packages have ridiculous awesome
coverage for their source code and take much longer to run than even
On Fri, 13 Apr 2007 21:29:29 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
Ciaran McCreesh wrote:
If a test suite isn't viable, the ebuild should be RESTRICTing test
anyway.
That means ALL the media applications, almost all the toolchain
applications, most languages and a couple of other
snip
Er, no, I'm explaining why enforcing src_test for EAPI 1 will be
helpful for an awful lot of Gentoo developers.
except that you back the tree into a corner that it cannot come out of
Huh? Not at all. If a package can't use its test suite, the ebuild can
set RESTRICT=test.
snip
The *only* downside that I can see here is that by default the package
installation process gets a little longer. To get around this some
method of globally opting out of src_test should be provided to the end
user, however since it is an on by default feature someone at least has
On Fri, 2007-04-13 at 12:17 -0700, Daniel Ostrow wrote:
snip
Er, no, I'm explaining why enforcing src_test for EAPI 1 will be
helpful for an awful lot of Gentoo developers.
except that you back the tree into a corner that it cannot come out of
Huh? Not at all. If a package
On Fri, 13 Apr 2007 18:18:27 +0100
Ciaran McCreesh [EMAIL PROTECTED] wrote:
On Fri, 13 Apr 2007 19:06:42 +0200
Jakub Moc [EMAIL PROTECTED] wrote:
Err, your suggestion was:
* Remove automatic directory making for do*
Because I was giving a one line summary, rather than a description of
On Friday 13 April 2007, Ciaran McCreesh wrote:
On Sat, 14 Apr 2007 00:02:29 +0200
Marius Mauch [EMAIL PROTECTED] wrote:
Because I was giving a one line summary, rather than a description
of the full change. The full description has been discussed
elsewhere several times.
I don't
On Fri, Apr 13, 2007 at 03:06:44PM -0400, Mike Frysinger wrote:
which doesnt apply here ... some packages have ridiculous awesome coverage
for
their source code and take much longer to run than even compile the package
Furthermore, there are packages with testcases where if you want them,
you
On Thu, 5 Apr 2007 15:11:47 -0700
Brian Harring [EMAIL PROTECTED] wrote:
Either way, EAPI=1 *should* have a bit more then just slot deps in my
opinion; very least it needs discussion to discern what folks want.
Well, EAPI 1 needs to be delivered quickly... So it's down to what
Portage can give
42 matches
Mail list logo
