Gentoo Archives: gentoo-dev

From: Mike Frysinger <vapier@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
Date: Fri, 13 Apr 2007 16:22:00
Message-Id: 200704131152.17004.vapier@gentoo.org
In Reply to: Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April) by Ciaran McCreesh
1 On Friday 13 April 2007, Ciaran McCreesh wrote:
2 > Mike Frysinger <vapier@g.o> wrote:
3 > > > It masks all kinds of programming screwups. doblah should make a
4 > > > blah, not make a blah and possibly make a directory.
5 > >
6 > > name one
7 >
8 > dosym's old behaviour prevented a broken Vim release (upstream screwed
9 > up a Makefile dependency) from getting into the tree unnoticed. Had
10 > that happened after you changed some (but not all) of the do*
11 > utilities, the duff symlinks would probably have gone unnoticed for a
12 > while.
13
14 improper package testing that was saved by a dosym that did not create
15 directories ... useful mayhaps, but not nearly enough to justify the proposed
16 change
17
18 > > you're proposing we suddenly bloat all of our src_install functions
19 > > for no gain at all ... sounds like a no brainer to me
20 >
21 > No, I'm proposing that functions not have strange side effects.
22
23 the behavior here is desired ... you install into a directory, then the
24 directory should exist
25
26 > Well no, they can't, because there are a whole load of ebuilds that
27 > will break if they do that. But if it's introduced as mandatory
28 > (barring ebuilds RESTRICTing it) for EAPI 1, the tree will slowly move
29 > towards everything that reasonably can do having working test suites,
30 > which will be a huge step forward for QA.
31
32 that's really the QA's job to enforce, not the package manager
33
34 if the QA team wants to spear head a tree wide effort at getting src_test up
35 and running, they're certainly free to
36 -mike

Replies

Subject Author
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April) Ciaran McCreesh <ciaranm@×××××××.org>