On Sun, 24 Jul 2016 12:17:56 +0200 Michał Górny <mgo...@gentoo.org> wrote:
> So what's the alternative? Design another eclass where ebuilds will > fail just the same because people will ignore the more explicit > requirement just the same as they do ignore the API? Sometimes you don't need a "new path", you just need to transition from the old behaviour to the new behaviour at a slower rate with more visibility. Option 1: Start off with them being QA Warnings instead of fatal errors and encourage end users to report them where they see them. Then after a cycle of warnings, you go through and fatalise them incrementally in order of "least likely to break the build in dangerous ways". Option 2: Bind the behaviour to an EAPI version that is not yet in use. Then, when that EAPI gets rolled out to the ebuilds getting upgrades, the strictures come into effect when the EAPI changes, giving maintainers fair opportunity to fix the problem before it rolls out to users. For me neither of these options say "don't do this thing", they're just "manage the bleeding better"
pgp4LnC2rcpnQ.pgp
Description: OpenPGP digital signature
