1 |
On 25/11/16 21:00, Jason Zaman wrote: |
2 |
> On Fri, Nov 25, 2016 at 08:27:12PM +1100, Michael Palimaka wrote: |
3 |
>> On 25/11/16 17:51, Jason Zaman wrote: |
4 |
>>>> Automation |
5 |
>>>> ========== |
6 |
>>>> |
7 |
>>>> It's easy to forget to check that all the required dependencies are in |
8 |
>>>> stable before filing a stabilisation test, but this wastes the actioning |
9 |
>>>> developer's time. I have prepared a bot that repoman checks the list of |
10 |
>>>> atoms and flags the bug appropriately. This allows easy filtering out of |
11 |
>>>> broken requests. |
12 |
>>> |
13 |
>>> This part would need to take into account DEPENDS ON in the bug too. |
14 |
>>> When I file my xfce lists I dep on the gnome stable bug since I need |
15 |
>>> the gtk stuff and if that isnt taken into account, repoman would just |
16 |
>>> die. |
17 |
>> |
18 |
>> The bot will either try its best to take into account bug dependencies, |
19 |
>> or otherwise just give up and skip such a bug. |
20 |
>> |
21 |
>>> I just realized there is another rare issue that we may have to take |
22 |
>>> into account. Some sets of packages *must* be stablized in lockstep. For |
23 |
>>> regular sets of packages like eg xfce if you leave off a bunch of the |
24 |
>>> extras its no big deal. |
25 |
>>> Eg for SELinux, the policy packages must all be stabilized all at |
26 |
>>> once because they depend on each other (I think perl is like this too?). |
27 |
>>> |
28 |
>>> We would need a way for maintainers to ask for testing without actually |
29 |
>>> committing. The maintainer can wait till everything is done and commit |
30 |
>>> everything at once himself. Some flag to make the tatt script skip the |
31 |
>>> step would be enough I think. |
32 |
>> |
33 |
>> Do you have a bug number handy so I can double check how the process |
34 |
>> normally looks? |
35 |
> |
36 |
> SwifT and I both run stable machines so we always just stabilize SELinux |
37 |
> stuff ourselves so dont have a bug number, no. |
38 |
> |
39 |
> its pretty much just: |
40 |
> cd sec-policy/ |
41 |
> ekeyword amd64 x86 */*-2.20151208-r6.ebuild |
42 |
> git add . |
43 |
> repoman full |
44 |
> repoman commit -m 'sec-policy: Stabilize selinux policy 2.20151208-r6' |
45 |
> |
46 |
> every single selinux policy package {,R}DEPENDs on |
47 |
> =sec-policy/selinux-base-policy-${PVR} |
48 |
> which in turn deps on |
49 |
> =sec-policy/selinux-base-${PVR} |
50 |
> and we always do everything with the same revision at the same time |
51 |
> otherwise you get lots of weirdness. For us, each arch could be done |
52 |
> separately (no point tho), the main part is that committing the packages |
53 |
> in a random order or even alphabetical doesnt really work. |
54 |
> |
55 |
> How aware of deps do we want to make such a tool? Having it figure out |
56 |
> the right order seems like a lot of work. Or we could force the script |
57 |
> to follow the order defined in the package list and then its up to the |
58 |
> maintainer. Then also if there is a failure either abort completely or |
59 |
> continue with the rest that it can (a. la --keep-going). |
60 |
|
61 |
Most tools I've seen address this by keywording the entire list of |
62 |
packages first, then doing the commit(s). tatt splits the entire process |
63 |
into multiple stages (build the package, build revdeps, keyword the |
64 |
ebuilds, git commit, ...) which can be run individually to maximise |
65 |
control to the person running it. |
66 |
|
67 |
That said, not everything needs a fancy tool. Your SELinux process looks |
68 |
pretty good the way it is. |