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:
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.
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]
On Tuesday 2020-12-22 17:03, Christian Boltz wrote:
Am Donnerstag, 17. Dezember 2020, 14:59:36 CET schrieb Fabian Vogt:
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.
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?
If you can do what you want, why ask for a restricting policy? ;-)
Hello, Am Dienstag, 22. Dezember 2020, 17:41:15 CET schrieb Jan Engelhardt:
On Tuesday 2020-12-22 17:03, Christian Boltz wrote:
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?
If you can do what you want, why ask for a restricting policy? ;-)
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:
Hello,
Am Dienstag, 22. Dezember 2020, 17:41:15 CET schrieb Jan Engelhardt:
On Tuesday 2020-12-22 17:03, Christian Boltz wrote:
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?
If you can do what you want, why ask for a restricting policy? ;-)
Because changing old entries in a .changes might be seen as problematic, and I'd even understand that point of view ;-)
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
Am Dienstag, 22. Dezember 2020, 17:03:24 CET schrieb Christian Boltz:
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.
A more modern approach to such issues are multibuilds, which would allow you to unify the specs again. Depending on their deviation, things could get ugly, though.. Pete
Moin, Am Dienstag, 22. Dezember 2020, 17:03:24 CET schrieb Christian Boltz:
Hello,
Am Donnerstag, 17. Dezember 2020, 14:59:36 CET schrieb Fabian Vogt:
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.
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?
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.
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?
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
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] _______________________________________________ openSUSE Factory mailing list -- factory@lists.opensuse.org To unsubscribe, email factory-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org
On Thu, 17 Dec 2020, Fabian Vogt wrote:
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
Is that true for maintained SLE / Leap codebases as well? Thanks, Richard.
Cheers, Fabian _______________________________________________ openSUSE Packaging mailing list -- packaging@lists.opensuse.org To unsubscribe, email packaging-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/packaging@lists.opensuse.org
-- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
Moin, Am Dienstag, 5. Januar 2021, 09:16:17 CET schrieb Richard Biener:
On Thu, 17 Dec 2020, Fabian Vogt wrote:
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
Is that true for maintained SLE / Leap codebases as well?
Not sure about SLE. If they use the same version of factory-auto as openSUSE, then yes. obs-service-source_validator might print a warning though. Cheers, Fabian
Thanks, Richard.
Cheers, Fabian _______________________________________________ openSUSE Packaging mailing list -- packaging@lists.opensuse.org To unsubscribe, email packaging-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/packaging@lists.opensuse.org
participants (6)
-
Christian Boltz -
Fabian Vogt -
Hans-Peter Jansen -
Jan Engelhardt -
Richard Biener -
Simon Lees