Hello, Am Sonntag, 19. Dezember 2021, 17:12:12 CET schrieb Lars Vogdt:
Am Sun, 19 Dec 2021 00:05:31 +0100 schrieb Christian Boltz:
I also found some more cleanup candidates - this time, I propose to disable the build for everything newer than 15.3 (which technically means "disable build by default, and only enable it for the currently enabled repos").
Please leave Tumbleweed enabled per default: This allows to easily see breaking changes in Tumbleweed, which is the Leap-ng. I know that people don't like to update their systems (mailman3, anyone? ;-) - but this does not help, as we are enforced to stay on a maintained system. So - as soon as the next Leap (15.4) get's stable, we will migrate our systems. As I don't like to do the migration all at once, I would love to see in front, if a package fails during development - means: if a package fails in Tumbleweed.
Seems I missed to mention a "detail" in my proposal - I want to disable the build for Tumbleweed and >= 15.4 __only for the packages listed in my mail__. [Note: This mail has an updated list, scroll down.] Does that sound better to you? For the other packages (especially those that are not in Tumbleweed or Leap), it makes sense to keep the build enabled as you proposed:
=> Default enabled repos: * Tumbleweed * Leap-ng (as soon, as it exists)
FYI: 15.4 is already in OBS, so... ;-) (but please wait with adding it to the infra repo until I finished the cleanup)
* Leap-current (15.3 atm) * Leap-maintained (15.2 until end of this year)
=> Rest only on demand. We could disable Leap-maintained as well, but I know that this will be too much work for some admins.
Agreed.
Packages that are exactly the same in openSUSE:infrastructure and Leap 15.3 according to "osc rdiff": - check_postgres - monitoring-plugins-bind9 - monitoring-plugins-count_file - monitoring-plugins-haproxy - monitoring-plugins-keepalived - monitoring-plugins-sar-perf
Hey, cool. This means that most of "my" packages ended in Leap :-)
:-)
But if you disable/remove them, please keep in mind that you have to do a "migration" ("zypper dup" or an explicit "zypper install *")of these packages on the affected systems. Otherwise these packages will never see any update.
I know, and that's why I'd keep them enabled for 15.3 and older so that we don't accidently" lock" these packages. When we zypper dup to 15.4, zypper should in theory ask for a vendor change.
Packages with only minor differences between openSUSE:infrastructure and Leap 15.3: - nrpe (only diff is "/bin/bash" -> "/{usr/,}bin/bash" in the AppArmor profile - not relevant for Leap 15.x)
Fine with me to delete this as well.
I'll adjust the build targets of these packages in a week in nobody objects.
I'd say: salt might be our friend here, to get the local packages migrated to their Leap versions.
Might also be an option, but it's more work than keeping 15.3 enabled and doing the vendor change when dup'ing to 15.4. BTW: There are some more packages that are in 15.3, but in an older version (and in some cases, it's the same version, but with less patches). I won't complain if someone pushes those packages to 15.4 so that we don't have to keep them in the infra repo. Which reminds me - I should run my script[1] again to compare 15.4 with the infra repo to see if some of them were already pushed ;-) Packages that are the same in Leap 15.4 and the infra repo (a few more than in the 15.3 vs. infra comparison): - apache2-mod_maxminddb - check_postgres - coturn - meson - monitoring-plugins-bind9 - monitoring-plugins-count_file - monitoring-plugins-haproxy - monitoring-plugins-keepalived - monitoring-plugins-sar-perf Packages with minor differences to Leap 15.4 that are not relevant for / not needed in the infrastructure repo: - nrpe (AppArmor profile change for /usr/bin/bash, see my previous mail) - nagios-rpm-macros (unbreak build for SLE 12 and RHEL 7, move macros.nagios to _rpmmacrodir) Any objections to disabling the build of these packages for >=15.4 and Tumbleweed? (We'll switch to the "official" packages on zypper dup.) Also, I'd say that we can/should disable the build for Tumbleweed for all packages that are linkpac'ed to openSUSE:Factory (because we get exactly the same package and only waste build power). Any objections? (I don't have a package list for that yet, and will probably have to check all linked packages manually. I'll send a report with the package list after doing the cleanup. Regards, Christian Boltz [1] what a big word for a few lines ;-) - but nevertheless, if someone is interested, I can share the script. -- Die erprobte Strategie der Managementmotivation im Operating [ist] eine, die ich gerne mit "Teile die Schmerzen" beschrieben möchte. Zum Beispiel setzt man den Projekteigentümer auf dieselbe Alerting-Methode wie den Sysadmin, der am Ende Sonntag nachts um 4 Uhr wegen eines Alarms die vorbeugende Wartung durchführen muß. [...] Wenn wir nun also einen jungen Projektverantwortlichen haben, bei dem das Handy Sonntag nachts um vier die Frau und das 6 Monate alte Kind weckt, dann ist diese Person nach einigen Wochen unmittelbaren Alerting-Erlebens sehr viel zugäng- licher. [http://blog.koehntopp.de/archives/2859-Wieso-zehn-Prozent.html]