On Friday 03 March 2006 23:32, Grant Goodyear wrote: > Stuart Herbert wrote: > > I agree. Adopting a policy like this is a low quality solution for > > servers. I've no opinion on how this affects desktops, but packages > > for servers need to be precise. A policy that says "if two USE > > flags deliver the same benefits, but conflict, pick one" is fine. But > > saying "flip a coin" ... how on earth is that "quality"? > > See my previous post. > > > And how the heck is it going to work w/ USE-based defaults? This > > creates a situation where package (b) cannot trust that a feature is > > enabled in package (a), even if package (a) was built with the > > required USE flags. > > Yep. Having a USE flag enabled turns out not to be a guarantee. That > said, package builds do become deterministic, so (for example) if one > needs to know if msmtp was built with openssl or gnutls it is easy > enough to pull the logic from the msmtp ebuild. I'm sure that there is > a more elegant solution, but I'm not convinced that having the user > randomly throw USE flags at a package until some combination works is > necessarily it. I could be wrong, however. *Shrug*
You mean the logic should be replicated between msmtp and all packages that need to know how it was built. I see this as a bigger source of bugs (msmtp changes, some of the dependants forget to change too) than verifying at setup time that the package has sane use flags. I'd prefer that a stage were introduced that runs at pretend time exactly for these things. I would say it is a bug if a useflag was specified for a package, including dependencies, and the package does not actually depend on it because the useflag was not actually applied. But even if the dependencies are proper, it is a bug from a HCI point of view. A package should deliver what it promisses. If it can't it should fail, not silently ignore the request. > > > Until Portage supports resolving conflicting USE flags when the > > deptree is built, the practical thing to do is for ebuilds w/ > > conflicting USE flags to bail. > > I, quite respectfully, disagree. As explained above, when an ebuild can not deliver, it should fail, not silently downgrade its features. Especially when other packages may depend on those features being present. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net
pgpgvlRFCHTSr.pgp
Description: PGP signature
