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