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 |