Gentoo Archives: gentoo-dev

From: Paul de Vrieze <pauldv@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] QA Roles v2
Date: Sat, 04 Mar 2006 13:36:50
Message-Id: 200603041434.08234.pauldv@gentoo.org
In Reply to: Re: [gentoo-dev] QA Roles v2 by Grant Goodyear
1 On Friday 03 March 2006 23:32, Grant Goodyear wrote:
2 > Stuart Herbert wrote:
3 > > I agree. Adopting a policy like this is a low quality solution for
4 > > servers. I've no opinion on how this affects desktops, but packages
5 > > for servers need to be precise. A policy that says "if two USE
6 > > flags deliver the same benefits, but conflict, pick one" is fine. But
7 > > saying "flip a coin" ... how on earth is that "quality"?
8 >
9 > See my previous post.
10 >
11 > > And how the heck is it going to work w/ USE-based defaults? This
12 > > creates a situation where package (b) cannot trust that a feature is
13 > > enabled in package (a), even if package (a) was built with the
14 > > required USE flags.
15 >
16 > Yep. Having a USE flag enabled turns out not to be a guarantee. That
17 > said, package builds do become deterministic, so (for example) if one
18 > needs to know if msmtp was built with openssl or gnutls it is easy
19 > enough to pull the logic from the msmtp ebuild. I'm sure that there is
20 > a more elegant solution, but I'm not convinced that having the user
21 > randomly throw USE flags at a package until some combination works is
22 > necessarily it. I could be wrong, however. *Shrug*
23
24 You mean the logic should be replicated between msmtp and all packages that
25 need to know how it was built. I see this as a bigger source of bugs (msmtp
26 changes, some of the dependants forget to change too) than verifying at setup
27 time that the package has sane use flags. I'd prefer that a stage were
28 introduced that runs at pretend time exactly for these things. I would say it
29 is a bug if a useflag was specified for a package, including dependencies,
30 and the package does not actually depend on it because the useflag was not
31 actually applied. But even if the dependencies are proper, it is a bug from a
32 HCI point of view. A package should deliver what it promisses. If it can't it
33 should fail, not silently ignore the request.
34
35 >
36 > > Until Portage supports resolving conflicting USE flags when the
37 > > deptree is built, the practical thing to do is for ebuilds w/
38 > > conflicting USE flags to bail.
39 >
40 > I, quite respectfully, disagree.
41
42 As explained above, when an ebuild can not deliver, it should fail, not
43 silently downgrade its features. Especially when other packages may depend on
44 those features being present.
45
46 Paul
47
48 --
49 Paul de Vrieze
50 Gentoo Developer
51 Mail: pauldv@g.o
52 Homepage: http://www.devrieze.net