| 1 |
On Mon, 10 Jul 2017 13:43:43 +0200 |
| 2 |
Pacho Ramos <pacho@g.o> wrote: |
| 3 |
|
| 4 |
> Yes, but it's similar as the cases when we need to fix our packages |
| 5 |
> to work with a newer library they depend on. In this case it would be |
| 6 |
> even easier as we can have multiple python versions and switch to the |
| 7 |
> newer one for testing while going back to the stable one (if |
| 8 |
> preferred) later. |
| 9 |
> |
| 10 |
|
| 11 |
I'm starting to think we need a collection of QA scripts in a repo |
| 12 |
somewhere, optimized for symlinking into /etc/portage/hooks/install/ |
| 13 |
|
| 14 |
And make it standard practice for: |
| 15 |
|
| 16 |
- Gentoo Devs to have those scripts |
| 17 |
- Tinderboxers' to have those scripts |
| 18 |
|
| 19 |
That's going to be the only way we can get these warnings in ways |
| 20 |
*developers* will see them, but: |
| 21 |
|
| 22 |
1. Won't needlessly clutter stable users systems |
| 23 |
2. Won't produce loads of ebuild bumps that do waves of metadata |
| 24 |
updates for things that don't affect end users. |
| 25 |
|
| 26 |
Presently the only things *like* this require hard-coded QA logic into |
| 27 |
portage itself, which, while useful, pulls us back to the whole problem |
| 28 |
where it might affect users, and becomes tightly coupled to portage's |
| 29 |
release cycle. |
| 30 |
|
| 31 |
We could however make things simpler, and have a package that installs |
| 32 |
these QA hacks into the hooks dir for us, and then it would be a matter |
| 33 |
of simply installing them via opt-in. |
Archives