Gentoo Archives: gentoo-dev

From: Jason Stubbs <jstubbs@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Detecting gcj in ebuilds
Date: Fri, 12 Nov 2004 13:18:47
Message-Id: 200411122220.29421.jstubbs@gentoo.org
In Reply to: Re: [gentoo-dev] Detecting gcj in ebuilds by Thomas de Grenier de Latour
1 On Friday 12 November 2004 01:04, Thomas de Grenier de Latour wrote:
2 > On Thu, 11 Nov 2004 21:57:41 +0900
3 >
4 > Jason Stubbs <jstubbs@g.o> wrote:
5 > > 1) Something Mr_Bones_ said - "Emerge should do the least amount
6 > > of work necessary to fulfill a user's request". That seems like
7 > > a logical statement to me. I also interpret that portage should
8 > > do it if it can as well.
9 >
10 > That seems logical, but sometimes warning the user that his
11 > request is stupid may be better for him. I mean, if emerging a
12 > fortran program implies two gcc merges, and then emerging another
13 > fortran program implies again two more gcc merges, etc., i think
14 > the user will not be that happy of having been blindly obeyed.
15
16 emerge --pretend will always show what emerge is going to do.
17
18 > > Example time. :)
19 >
20 > I think it may help to also look at real world examples. As a
21 > beginning, a quick grep on "re-emerge" in current tree gives me:
22 <SNIP>
23 > that in most cases, this deps are at least RDEPEND deps. That means that if
24 > we want emerge to preserve system consistency (installed packages respect
25 > make.conf+package.use flags), there is nothing clever to do for emerge, but
26 > to fail at depend time and ask the user to change his flags and re-emerge
27 > some packages (that is Olivier's example #7).
28 >
29 > So my opinion is that, _so far_, there seems to be no real need
30 > for the clever solution you've proposed, and that the simpler
31 > check and failure approach would be enough. But sure, that may not
32 > be true anymore in the future (or with some packages that i've
33 > missed).
34
35 unixODBC-2.2.8.ebuild:DEPEND="qt? ( >=x11-libs/qt-3.0* )"
36 qt-3.3.3-r1.ebuild:DEPEND="odbc? ( dev-db/unixODBC )"
37
38 Don't let that '*' in unixODBC's DEPEND confuse you - that's somebody's
39 misunderstanding and should be written as >=x11-libs/qt-3. This is one case
40 that already exists in the tree and I'm certain that there are others. Even
41 if there were no existing cases at present, not implementing it from the
42 start is just a guaranteed bug. If the dep resolver has to be rewritten
43 anyway, why not bring it up to scratch?
44
45 Regards,
46 Jason Stubbs
47
48 --
49 gentoo-dev@g.o mailing list

Replies

Subject Author
Re: [gentoo-dev] Detecting gcj in ebuilds Dan Armak <danarmak@g.o>
Re: [gentoo-dev] Detecting gcj in ebuilds Thomas de Grenier de Latour <degrenier@×××××××××××.fr>