1 |
On 1/18/21 8:42 PM, Alec Warner wrote: |
2 |
> On Mon, Jan 18, 2021 at 8:09 PM Zac Medico <zmedico@g.o> wrote: |
3 |
>> |
4 |
>> On 1/18/21 6:07 PM, Alec Warner wrote: |
5 |
>>> On Fri, Jan 15, 2021 at 6:47 PM Matt Turner <mattst88@g.o> wrote: |
6 |
>>>> |
7 |
>>>> This set is the upgradable packages for which the highest visible |
8 |
>>>> version has a different subslot than the currently installed version. |
9 |
>>>> |
10 |
>>>> The primary purpose of this feature is for use in catalyst builds. We |
11 |
>>>> update the "seed" stage3 before using it to build a new stage1. |
12 |
>>>> |
13 |
>>>> Updating the entire stage is expensive and unnecessary (since we're |
14 |
>>>> going to build the latest packages in stage1 and then rebuild everything |
15 |
>>>> in stage3). |
16 |
>>>> |
17 |
>>>> What we definitely do need to update in the original stage3 however, is |
18 |
>>>> any package that would trigger a subslot rebuild. |
19 |
>>>> |
20 |
>>>> For example: gcc links with libmpfr.so from dev-libs/mpfr. mpfr's SONAME |
21 |
>>>> changes from libmpfr.so.4 (SLOT="0/4") to libmpfr.so.6 (SLOT="0/6"). If |
22 |
>>>> the seed stage's dev-libs/mpfr is not updated before emerging gcc, gcc |
23 |
>>>> will link with libmpfr.so.4, but the latest version of dev-libs/mpfr |
24 |
>>>> will be built and libmpfr.so.6 included into the stage1. Since the old |
25 |
>>>> libmpfr.so.4 is not included in the stage1, gcc will not work, breaking |
26 |
>>>> subsequent stage builds. |
27 |
>>>> |
28 |
>>>> Our current options to update the seed are too large a hammer (e.g., |
29 |
>>>> "--update --deep --newuse @world" or "--update --deep --newuse |
30 |
>>>> --complete-graph --rebuild-if-new-ver gcc") and spend too much time |
31 |
>>>> updating seed stages for no gain beyond updating only packages for whom |
32 |
>>>> the subslot has changed. |
33 |
>>>> |
34 |
>>>> With this set, catalyst will likely use |
35 |
>>>> |
36 |
>>>> emerge @changed-subslot --ignore-built-slot-operator-deps y |
37 |
>>>> |
38 |
>>>> to update the seed stage. |
39 |
>>>> |
40 |
>>>> Thank you to Zac Medico for showing me how to do this. |
41 |
>>>> |
42 |
>>>> Bug: https://bugs.gentoo.org/739004 |
43 |
>>>> Signed-off-by: Matt Turner <mattst88@g.o> |
44 |
>>>> --- |
45 |
>>>> cnf/sets/portage.conf | 5 +++++ |
46 |
>>>> lib/portage/_sets/dbapi.py | 39 +++++++++++++++++++++++++++++++++++++- |
47 |
>>>> 2 files changed, 43 insertions(+), 1 deletion(-) |
48 |
>>>> |
49 |
>>>> diff --git a/cnf/sets/portage.conf b/cnf/sets/portage.conf |
50 |
>>>> index 22f0fa3a5..5651a9c53 100644 |
51 |
>>>> --- a/cnf/sets/portage.conf |
52 |
>>>> +++ b/cnf/sets/portage.conf |
53 |
>>>> @@ -84,6 +84,11 @@ exclude-files = /usr/bin/Xorg |
54 |
>>>> [rebuilt-binaries] |
55 |
>>>> class = portage.sets.dbapi.RebuiltBinaries |
56 |
>>>> |
57 |
>>>> +# Installed packages for which the subslot of the highest visible ebuild |
58 |
>>>> +# version is different than the currently installed version. |
59 |
>>>> +[changed-subslot] |
60 |
>>>> +class = portage.sets.dbapi.SubslotChangedSet |
61 |
>>>> + |
62 |
>>>> # Installed packages for which the highest visible ebuild |
63 |
>>>> # version is lower than the currently installed version. |
64 |
>>>> [downgrade] |
65 |
>>>> diff --git a/lib/portage/_sets/dbapi.py b/lib/portage/_sets/dbapi.py |
66 |
>>>> index 52367c4a6..46ba5c17d 100644 |
67 |
>>>> --- a/lib/portage/_sets/dbapi.py |
68 |
>>>> +++ b/lib/portage/_sets/dbapi.py |
69 |
>>>> @@ -15,7 +15,7 @@ from portage._sets import SetConfigError, get_boolean |
70 |
>>>> import portage |
71 |
>>>> |
72 |
>>>> __all__ = ["CategorySet", "ChangedDepsSet", "DowngradeSet", |
73 |
>>>> - "EverythingSet", "OwnerSet", "VariableSet"] |
74 |
>>>> + "EverythingSet", "OwnerSet", "SubslotChangedSet", "VariableSet"] |
75 |
>>>> |
76 |
>>>> class EverythingSet(PackageSet): |
77 |
>>>> _operations = ["merge"] |
78 |
>>>> @@ -167,6 +167,43 @@ class VariableSet(EverythingSet): |
79 |
>>>> |
80 |
>>>> singleBuilder = classmethod(singleBuilder) |
81 |
>>>> |
82 |
>>>> +class SubslotChangedSet(PackageSet): |
83 |
>>>> + |
84 |
>>>> + _operations = ["merge", "unmerge"] |
85 |
>>>> + |
86 |
>>>> + description = "Package set which contains all packages " + \ |
87 |
>>>> + "for which the subslot of the highest visible ebuild is " + \ |
88 |
>>>> + "different than the currently installed version." |
89 |
>>> |
90 |
>>> description = ("string1", |
91 |
>>> "string2", |
92 |
>>> "string3") |
93 |
>>> |
94 |
>>> vs concat + \ for line continuation? |
95 |
>>> |
96 |
>>> -A |
97 |
>> |
98 |
>> We also got flak on irc about the classmethod(singleBuilder) usage as |
99 |
>> opposed to @classmethod. This package set is formatted exactly like |
100 |
>> others in the file, so it's just a copy / paste thing. |
101 |
> |
102 |
> Ack, I can send a patch. I don't watch all these CLs. |
103 |
> |
104 |
> PEP8 is fairly clear about line continuations (\) and whey are |
105 |
> appropriate (e.g. not here.) |
106 |
> I don't think the pep cares about classmethod() vs @classmethod (and I |
107 |
> don't really care either.) |
108 |
> |
109 |
> I personally find: |
110 |
> |
111 |
> a = "foo" + " bar" + \ |
112 |
> "baz" |
113 |
> |
114 |
> jarring; as compared to: |
115 |
> |
116 |
> a = ("foo", "bar", |
117 |
> "baz") |
118 |
> |
119 |
|
120 |
Me too, parenthesis look much better. |
121 |
|
122 |
> but then you have to know that python will implicitly join these |
123 |
> strings together, which is unfortunate, butl I attempt to write python |
124 |
> assuming readers know python (so I'm not worried about readers knowing |
125 |
> implicit string join.) There are probably 5 other ways to write this |
126 |
> block (""" strings, ''.join(), string.format(), some other stuff.) |
127 |
|
128 |
Implicit join works for me. Let's assume readers know python or will |
129 |
learn it. |
130 |
|
131 |
>> |
132 |
>> On the topic of python formatting, maybe we should use something like |
133 |
>> https://github.com/psf/black to automate it? |
134 |
> |
135 |
> I've used black before, my recollection was that you can't disable |
136 |
> stuff, and this leads to situations where black and other tools |
137 |
> disagree about a thing, and then you have to stop the tools from |
138 |
> fighting. |
139 |
> This is mentioned in the black readme (e.g. black often fights with |
140 |
> isort.) |
141 |
|
142 |
I think black is more valuable than isort, so in the worst case I'd |
143 |
choose to disable isort (and we're not even using it yet). |
144 |
|
145 |
> It also means we need to send a giant set of patches to format |
146 |
> with black...I'd like to think we have enough test coverage for this |
147 |
> (after the previous linting changes.) |
148 |
|
149 |
Yeah I think the test coverage is fine for this. |
150 |
|
151 |
> I'm not opposed, just understand |
152 |
> that as the human doing most of the merges, you might end up being the |
153 |
> human also making the tools not fight ;) |
154 |
|
155 |
I'm willing to struggle with it a bit, but yeah if it becomes too |
156 |
painful then my plan would be to disable isort. |
157 |
-- |
158 |
Thanks, |
159 |
Zac |