On Mon, 9 Mar 2009 20:26:24 +0000
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> * src_test run unless RESTRICTed or explicitly disabled by the user
> (bug 184812)

This one is not uncontroversial and will not go in a 'quick' EAPI I
think.

/loki_val

On Mon, 9 Mar 2009 15:39:41 -0700
Donnie Berkholz <dberkholz@gentoo.org> wrote:
> > * Calling unpack on an unrecognised extension should be fatal,
> > unless --if-compressed is specified. The default src_unpack needs
> > to use this.
>
> Why?

Currently, if a package does an explicit 'unpack foo.bar', where .bar is
an unsupported archive format, unpack just does nothing. This isn't a
good default behaviour; if a package really wants something to be
ignored silently, it should have to say so.

--
Ciaran McCreesh

On Mon, 09 Mar 2009 17:38:51 -0500
Jeremy Olexa <darkside@gentoo.org> wrote:
> Should the next EAPI (as proposed) be a major "release" in terms of
> naming?

We don't use major.minor numbers for EAPI or have a concept like that.
It's too much mess.

> And should it really be adding features?

Well... So far as I can see, the main driving force behind all of this
is the immediate need for [use(+)] deps (since developers don't want to
have to mess around with complex || statements), and [use(+)] is most
definitely a new feature.

> With that said, can't bug fixes be implemented without an EAPI bump?

If we screw up the specification and catch it early enough on, then
yes. But [use(+)] really isn't a bug fix...

--
Ciaran McCreesh

Hi,

Ciaran McCreesh <ciaran.mccreesh@googlemail.com>:

> On Mon, 9 Mar 2009 23:20:03 +0100
> Christian Faulhammer <fauli@gentoo.org> wrote:
> > Package A goes stable, test suite passes. Package B (a dependency
> > of A) goes stable in a newer version, which will cause A to not
> > merge in stable profile. This happens all the time and is no
> > special case.
>
> Uh, you *are* testing things that use a library before you stable that
> library, right?

When I was an architecture developer I tried to. But when stabilising
a minor version of curl (for example), testing all reverse dependencies
is no option. But this broke tests for Bazaar for example in stable.
Or another issue. Badly written Autoconf systems which will break in
src_test() with a different version of intltool, which is not a direct
dependency. That pitfall hit me several times in the last years.
The more, x86 e.g. ranges from embedded Geode platforms to dual core
desktop systems and running the sqlite test suite on the first is no
fun. As a user I would not accept two hours of build time.
Test-driven development is great, but not so widely used as one could
wish it to be.

> Besides, if a newer version of a library breaks a package using it,
> you most definitely want to know about it before you end up merging
> something that won't work. If src_test is failing where it used to
> work, it's a very good sign that something's broken, and you shouldn't
> be carrying on.

Arch devs run test suites and won't stabilise if it fails (except some
special cases).

V-Li

--
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://www.faulhammer.org/>

On Mon, Mar 9, 2009 at 3:25 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Mon, 9 Mar 2009 23:20:03 +0100
> Christian Faulhammer <fauli@gentoo.org> wrote:
>> Package A goes stable, test suite passes. Package B (a dependency of
>> A) goes stable in a newer version, which will cause A to not merge in
>> stable profile. This happens all the time and is no special case.
>
> Uh, you *are* testing things that use a library before you stable that
> library, right?

You can't test everything. I think for a small project like exherbo
where everyone basically sees eye to eye on a number of ideas this
works great. Everyone agrees testing is super and they will fix
broken tests or RESTRICT them. But Gentoo is bigger, and people have
varying opinions, and on this topic the opinions are rather strong; so
I kindly ask that you drop it. There are plenty of other far more
useful features on your list that are worth your time and will
actually slide through rather quickly

>
> Besides, if a newer version of a library breaks a package using it, you
> most definitely want to know about it before you end up merging
> something that won't work. If src_test is failing where it used to
> work, it's a very good sign that something's broken, and you shouldn't
> be carrying on.
>
> --
> Ciaran McCreesh
>

On Mon, 2009-03-09 at 15:39 -0700, Donnie Berkholz wrote:

> > * Utility commands, even the ones that aren't functions, should die. To
> > get a non-die version, prefix the command with nonfatal (e.g.
> > 'nonfatal dodoc README', which just returns non-zero on failure
> > rather than splatting).
>
> Sounds useful to have less '|| die' all over the place.

Whats wrong with 'set -e' and doing '|| true' behind?
IMO this would feel more shell-ish.

/haubi/
--
Michael Haubenwallner
Gentoo on a different level

On Tue, 10 Mar 2009 00:25:49 +0100
Christian Faulhammer <fauli@gentoo.org> wrote:
> > Uh, you *are* testing things that use a library before you stable
> > that library, right?
>
> When I was an architecture developer I tried to. But when
> stabilising a minor version of curl (for example), testing all
> reverse dependencies is no option. But this broke tests for Bazaar
> for example in stable.

Then this is a legitimate problem that someone needs to know about and
fix. So having src_test turned on globally is a *good* thing.

> Badly written Autoconf systems which will break in src_test() with a
> different version of intltool, which is not a direct dependency.

Again, finding this is good.

> That pitfall hit me several times in the last years. The more, x86
> e.g. ranges from embedded Geode platforms to dual core desktop
> systems and running the sqlite test suite on the first is no fun. As
> a user I would not accept two hours of build time. Test-driven
> development is great, but not so widely used as one could wish it to
> be.

And if you're on an especially slow platform, as a user you can turn
tests off.

--
Ciaran McCreesh

On Tue, 10 Mar 2009 10:08:06 +0100
Michael Haubenwallner <haubi@gentoo.org> wrote:
> Whats wrong with 'set -e' and doing '|| true' behind?

Waaaaaaay too many false positives.

--
Ciaran McCreesh

On Mon, 9 Mar 2009 20:58:40 -0700
Alec Warner <antarus@gentoo.org> wrote:
> You can't test everything. I think for a small project like exherbo
> where everyone basically sees eye to eye on a number of ideas this
> works great. Everyone agrees testing is super and they will fix
> broken tests or RESTRICT them. But Gentoo is bigger, and people have
> varying opinions, and on this topic the opinions are rather strong; so
> I kindly ask that you drop it. There are plenty of other far more
> useful features on your list that are worth your time and will
> actually slide through rather quickly

Well, the alternative is to drop src_test all together. If a test
failure is meaningless, having the test is meaningless.

--
Ciaran McCreesh

On Sun, 08 Mar 2009 08:49:16 +0100
Tiziano Müller <dev-zero@gentoo.org> wrote:
> With eapis 1 and 2 we introduced nice features but also a couple of
> new problems. One of them are the use dependencies when the package
> you depend on doesn't have the use flag anymore (see [1] for an
> example).

Here's another one to consider:

If S= is wrong (which it often is, for packages with icky tarballs),
src_configure and src_compile won't error out. These days this isn't a
huge deal, because your custom src_install will probably fail. But if
we're introducing a default src_install, it will instead see no
Makefile and just do nothing, resulting in an empty package being
installed.

Currently, at the start of src_configure, the package manager does a cd
to ${S} if ${S} exists, and to ${WORKDIR} otherwise. I'd like to
propose that ${S} not existing should instead be an error if either of
the following conditions are met:

* ${A} is non-empty
* Any of src_unpack, src_configure, src_compile or src_install is a
defined phase.

Ebuilds where this would trigger a false positive would have to specify
S=${WORKDIR}.

--
Ciaran McCreesh