On Mon, 10 Jul 2017 13:43:43 +0200 Pacho Ramos <pa...@gentoo.org> wrote:
> Yes, but it's similar as the cases when we need to fix our packages > to work with a newer library they depend on. In this case it would be > even easier as we can have multiple python versions and switch to the > newer one for testing while going back to the stable one (if > preferred) later. > I'm starting to think we need a collection of QA scripts in a repo somewhere, optimized for symlinking into /etc/portage/hooks/install/ And make it standard practice for: - Gentoo Devs to have those scripts - Tinderboxers' to have those scripts That's going to be the only way we can get these warnings in ways *developers* will see them, but: 1. Won't needlessly clutter stable users systems 2. Won't produce loads of ebuild bumps that do waves of metadata updates for things that don't affect end users. Presently the only things *like* this require hard-coded QA logic into portage itself, which, while useful, pulls us back to the whole problem where it might affect users, and becomes tightly coupled to portage's release cycle. We could however make things simpler, and have a package that installs these QA hacks into the hooks dir for us, and then it would be a matter of simply installing them via opt-in.
pgpjIUlgPDDQ6.pgp
Description: OpenPGP digital signature
