On 07/10/2017 11:35 PM, Kent Fredric wrote: > 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 In addition to the checks that are bundled, Portage already natively supports custom post-install QA checks in:
* /usr/local/lib/install-qa-check.d * /usr/lib/install-qa-check.d * $REPO/metadata/install-qa-check.d It's just a matter of someone writing and shipping them. I've been very slowly preparing a collection based on the common type of tinderboxing bugs that are filed and porting parts of lintian, but I haven't finished yet.
