Multi-spec packages only need a single .changes file now
Hi, Previously, packages with multiple spec files (e.g. systemd, which has both systemd.spec and systemd-mini.spec) needed a .changes file for each .spec. As the vast majority of changes (e.g. version updates) affect all "flavors", this requirement got dropped and only a single .changes file with the name used for the submit request is needed. It's used for all .spec files during build. References: https://github.com/openSUSE/obs-service-source_validator/pull/88 https://github.com/openSUSE/openSUSE-release-tools/pull/2507 Cheers, Fabian
Hello, Am Donnerstag, 17. Dezember 2020, 14:59:36 CET schrieb Fabian Vogt:
What's the recommended way for existing packages with multiple spec files? Merge the changes files into one, or keep separate changes files for each spec? I'm especially asking about the apparmor (and libapparmor) package: https://build.opensuse.org/package/show/security:apparmor/apparmor libapparmor was split into its own spec to fix a build dependency loop, and libapparmor.changes contains only libapparmor-related changes - but most of that information is also in apparmor.changes. What's your recommendation in this case? Bonus question: will the package still build for Leap 15.x with only one changes file? Regards, Christian Boltz -- Natürlich kann ich Traktor fahren. Ich bin der geborene Traktorfahrer. Es dürfte dir schwer fallen, jemanden zu finden, der annähernd so perfekt Traktor fährt wie ich. Ja, ich _bin_ geradezu ein Traktor. Wieviele Räder hat so ein Traktor eigentlich? [Ratti]
Hello, Am Dienstag, 22. Dezember 2020, 17:41:15 CET schrieb Jan Engelhardt:
Because changing old entries in a .changes might be seen as problematic, and I'd even understand that point of view ;-) That's why I ask about the recommended way instead of just doing it and then getting the merged .changes file rejected ;-) Regards, Christian Boltz -- We break the translation consistently (wow, consistent break, I like that wording) [from https://bugzilla.novell.com/show_bug.cgi?id=165509]
On 12/23/20 6:27 AM, Christian Boltz wrote:
Its not, it happens all the time, regularly new CVE / bug numbers are added to existing entries. People only really get upset if you remove information. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
Moin, Am Dienstag, 22. Dezember 2020, 17:03:24 CET schrieb Christian Boltz:
If switching over saves some work and duplication, it's probably worth it (especially if migration is just deleting a file). In the case that the .changes files have vastly different content, migration might be more work and only makes sense if the merged .changes actually fits all built packages.
It looks like libapparmor.changes is a subset of apparmor.changes, so only keeping one of them would avoid the duplication. The package is called apparmor, so keeping just apparmor.changes should work. That's assuming that libapparmor.changes doesn't contain any additional bug refs which aren't in apparmor.changes.
Bonus question: will the package still build for Leap 15.x with only one changes file?
Yes, the handling of that is done by OBS itself and the bots won't reject it either. obs-service-source_validator in Leap might print a warning though. Cheers, Fabian
On Thu, 17 Dec 2020, Fabian Vogt wrote:
Is that true for maintained SLE / Leap codebases as well? Thanks, Richard.
-- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
Hello, Am Donnerstag, 17. Dezember 2020, 14:59:36 CET schrieb Fabian Vogt:
What's the recommended way for existing packages with multiple spec files? Merge the changes files into one, or keep separate changes files for each spec? I'm especially asking about the apparmor (and libapparmor) package: https://build.opensuse.org/package/show/security:apparmor/apparmor libapparmor was split into its own spec to fix a build dependency loop, and libapparmor.changes contains only libapparmor-related changes - but most of that information is also in apparmor.changes. What's your recommendation in this case? Bonus question: will the package still build for Leap 15.x with only one changes file? Regards, Christian Boltz -- Natürlich kann ich Traktor fahren. Ich bin der geborene Traktorfahrer. Es dürfte dir schwer fallen, jemanden zu finden, der annähernd so perfekt Traktor fährt wie ich. Ja, ich _bin_ geradezu ein Traktor. Wieviele Räder hat so ein Traktor eigentlich? [Ratti]
Hello, Am Dienstag, 22. Dezember 2020, 17:41:15 CET schrieb Jan Engelhardt:
Because changing old entries in a .changes might be seen as problematic, and I'd even understand that point of view ;-) That's why I ask about the recommended way instead of just doing it and then getting the merged .changes file rejected ;-) Regards, Christian Boltz -- We break the translation consistently (wow, consistent break, I like that wording) [from https://bugzilla.novell.com/show_bug.cgi?id=165509]
On 12/23/20 6:27 AM, Christian Boltz wrote:
Its not, it happens all the time, regularly new CVE / bug numbers are added to existing entries. People only really get upset if you remove information. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
Moin, Am Dienstag, 22. Dezember 2020, 17:03:24 CET schrieb Christian Boltz:
If switching over saves some work and duplication, it's probably worth it (especially if migration is just deleting a file). In the case that the .changes files have vastly different content, migration might be more work and only makes sense if the merged .changes actually fits all built packages.
It looks like libapparmor.changes is a subset of apparmor.changes, so only keeping one of them would avoid the duplication. The package is called apparmor, so keeping just apparmor.changes should work. That's assuming that libapparmor.changes doesn't contain any additional bug refs which aren't in apparmor.changes.
Bonus question: will the package still build for Leap 15.x with only one changes file?
Yes, the handling of that is done by OBS itself and the bots won't reject it either. obs-service-source_validator in Leap might print a warning though. Cheers, Fabian
participants (6)
-
Christian Boltz -
Fabian Vogt -
Hans-Peter Jansen -
Jan Engelhardt -
Richard Biener -
Simon Lees