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
-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 ->
>>
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
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 defa
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 do
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'
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 tur
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
> > 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
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 nee
Christopher Sawtell wrote:
> Indeed, but speaking as a user, one wants the application to build and work,
> that is after all the whole point of installing a package.
If you have it on the tree it is supposed to work or at least have
passed a round of tests on the developer system, so you don't w
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
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 n
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,
y
On Friday 13 April 2007, Daniel Ostrow wrote:
> 1). Even though src_test is not mandatory in the here and now any
> package that provides a test suite that fails said tests has a bug. It
> may not be a critical bug but it is in fact a bug.
>
> 2). The proper fix, again in the here and now, for said
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.
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 remember any discussion about this, so a more s
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 d
On Fri, 2007-04-13 at 12:17 -0700, Daniel Ostrow wrote:
>
>
> > > > 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.
> 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
> *tried
> > > 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=te
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
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 e
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 y
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
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
>
> 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 e
> > > 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
> > > fut
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 d
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 dir
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 time
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
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 c
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 behavio
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
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 Friday 13 April 2007, Ciaran McCreesh wrote:
> 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 (up
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.
> >
> > na
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
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 Makef
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 poss
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 bla
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
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
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
Ciaran McCreesh wrote:
> * Remove automatic directory making for do*
Why?
lu
--
Luca Barbato
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
[EMAIL PROTECTED] mailing list
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 g
47 matches
Mail list logo
