>> Oh yeah,and who said we really needed more than one use case? I think >> providing tools to allow Gentoo to be adopted in the corporate >> environment is reason enough to have binary package support, and I feel >> that many people will agree with me. >> Well I'm sure you'll be over the moon to know I do ;) > > The issue isn't whether or not we should have them, or for that matter > whether or not there is more then one use case. The issue is making sure > that we know what the use cases are to ensure that the tools we have are > flexible enough to be able to support every case and so that we don't > paint ourselves into a corner by making decisions before we know how > people plan on using the tool. > Agreed, but the actual mechanism in question is only adds functionality; nothing is being taken away aiui. As to it borking use cases, surely it's better to explain which use case it breaks than get into a nitpick about whether there might be any others. After all that's why there's an externally-facing list: so people can chime in with their concerns.
The discussion on default policy doesn't change the fact that it is a needed mechanism, imo. Having it as a switch in FEATURES makes a lot of sense, and i think that ensuring Gentoo systems won't leak sensitive information, unless explicitly told to, is a worthwhile objective. A warning when adding sensitive files to a binpkg seems like a wise idea, especially if it is a set and forget flag. (Devs can always tweak an env var, users who've lost data are harder to mollify.) -- [EMAIL PROTECTED] mailing list