1 |
On 11 Jul 2017 01:41, Kristian Fiskerstrand <k_f@g.o> wrote: |
2 |
> |
3 |
> On 07/10/2017 03:35 PM, Kent Fredric wrote: |
4 |
> > On Mon, 10 Jul 2017 13:43:43 +0200 |
5 |
> > Pacho Ramos <pacho@g.o> wrote: |
6 |
> > |
7 |
> >> Yes, but it's similar as the cases when we need to fix our packages |
8 |
> >> to work with a newer library they depend on. In this case it would be |
9 |
> >> even easier as we can have multiple python versions and switch to the |
10 |
> >> newer one for testing while going back to the stable one (if |
11 |
> >> preferred) later. |
12 |
> >> |
13 |
> > |
14 |
> > I'm starting to think we need a collection of QA scripts in a repo |
15 |
> > somewhere, optimized for symlinking into /etc/portage/hooks/install/ |
16 |
> > |
17 |
> |
18 |
> I might've read things too quickly, we're not talking a repoman check here? |
19 |
|
20 |
Not sure repoman is enough here. |
21 |
|
22 |
But I'm just saying I see a growing number of problems that can only be detected by actually building the package, and can't be done with static analysis. |
23 |
|
24 |
And then, some of those that can be addressed with repoman are annoying to solve with repoman, as you're tying your release cycle to repomans. |
25 |
|
26 |
And what if your check needs external tools? Surely repoman would be a terrible place to put those dependencies |
27 |
> |
28 |
> -- |
29 |
> Kristian Fiskerstrand |
30 |
> OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net |
31 |
> fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 |
32 |
> |
33 |
|
34 |
-- |