[opensuse-packaging] RFC: Guidelines change: obsolete systemd requirements
Hi, The section "(Build) Requirements" in https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines#.28Build.29_Re... is obsolete as rpm-build requires systemd-rpm-macros and the bcond is not relevant on current distros anymore. Therefore I propose to remove the section without replacement. Following the change process¹ the update will be applied if there are no strong objections within 14 days. cu Ludwig [1] https://en.opensuse.org/openSUSE:Packaging_guidelines_change_process#Process... -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, HRB 36809 (AG Nürnberg), GF: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Tue, Jul 14, Ludwig Nussel wrote:
Hi,
The section "(Build) Requirements" in https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines#.28Build.29_Re... is obsolete as rpm-build requires systemd-rpm-macros and the bcond is not relevant on current distros anymore.
Therefore I propose to remove the section without replacement.
In this regard, is the "BuildRequires: pkgconfig(systemd)" in the examples on that page really correct? For what do I need this BuildRequires if I package some sytemd units, but don't link against systemd? Thorsten
Following the change process¹ the update will be applied if there are no strong objections within 14 days.
cu Ludwig
[1] https://en.opensuse.org/openSUSE:Packaging_guidelines_change_process#Process...
-- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, HRB 36809 (AG Nürnberg), GF: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
-- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wednesday 2020-07-15 08:51, Thorsten Kukuk wrote:
The section "(Build) Requirements" in https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines#.28Build.29_Re... is obsolete as rpm-build requires systemd-rpm-macros and the bcond is not relevant on current distros anymore.
Therefore I propose to remove the section without replacement.
In this regard, is the "BuildRequires: pkgconfig(systemd)" in the examples on that page really correct? For what do I need this BuildRequires if I package some sytemd units, but don't link against systemd?
Ah, so that's where all the bad specfiles come from :-/ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wed, Jul 15, 2020 at 5:56 AM Jan Engelhardt <jengelh@inai.de> wrote:
On Wednesday 2020-07-15 08:51, Thorsten Kukuk wrote:
The section "(Build) Requirements" in https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines#.28Build.29_Re... is obsolete as rpm-build requires systemd-rpm-macros and the bcond is not relevant on current distros anymore.
Therefore I propose to remove the section without replacement.
In this regard, is the "BuildRequires: pkgconfig(systemd)" in the examples on that page really correct? For what do I need this BuildRequires if I package some sytemd units, but don't link against systemd?
For those who don't know, systemd.pc is just a file full of path variables. If a program's build script can read this, it will be able to auto-detect the platform's systemd unit path configuration, among other things. It's essentially the build script equivalent of the upstream systemd rpm macros. If you want to *link* to systemd, you need to use libsystemd.pc. That contains the standard pkgconfig information used for detecting the library and linking to it. And of course, finally systemd-rpm-macros is the package that contains the rpm macros used for packaging stuff using systemd features. :) -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Thorsten Kukuk wrote:
On Tue, Jul 14, Ludwig Nussel wrote:
Hi,
The section "(Build) Requirements" in
https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines#.28Build.29_Re...
is obsolete as rpm-build requires systemd-rpm-macros and the bcond is not relevant on current distros anymore.
Therefore I propose to remove the section without replacement.
In this regard, is the "BuildRequires: pkgconfig(systemd)" in the examples on that page really correct? For what do I need this BuildRequires if I package some sytemd units, but don't link against systemd?
I missed that but looks like you just changed it in the wiki. What's the point of the documented change process that I tried to follow here then if people just randomly modify the wiki? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, HRB 36809 (AG Nürnberg), GF: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Fri, Jul 17, 2020 at 7:34 AM Ludwig Nussel <ludwig.nussel@suse.de> wrote:
Thorsten Kukuk wrote:
On Tue, Jul 14, Ludwig Nussel wrote:
Hi,
The section "(Build) Requirements" in
https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines#.28Build.29_Re...
is obsolete as rpm-build requires systemd-rpm-macros and the bcond is not relevant on current distros anymore.
Therefore I propose to remove the section without replacement.
In this regard, is the "BuildRequires: pkgconfig(systemd)" in the examples on that page really correct? For what do I need this BuildRequires if I package some sytemd units, but don't link against systemd?
I missed that but looks like you just changed it in the wiki. What's the point of the documented change process that I tried to follow here then if people just randomly modify the wiki?
This brings up something that has been tickling at the back of my mind since it was discussed last year at SUSECON and oSC. We should strongly consider migrating our packaging guidelines *out* of the openSUSE Wiki into a documentation site system. Wikis are terrible for navigation, discovery, SEO, and content control. Fedora migrated their guidelines out of the wiki last year[1][2] and Debian has always had theirs not in a wiki[3]. When Fedora moved, they were able to simplify their change control process to just "make a pull request and the packaging committee would review it". I'm not saying that we have to exactly replicate that process, but pulling it out of the wiki and using a docs system for documentation would be nice... [1]: https://docs.fedoraproject.org/en-US/packaging-guidelines/ [2]: https://pagure.io/packaging-committee [3]: https://www.debian.org/doc/debian-policy/ -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Neal Gompa wrote:
[...] This brings up something that has been tickling at the back of my mind since it was discussed last year at SUSECON and oSC. We should strongly consider migrating our packaging guidelines *out* of the openSUSE Wiki into a documentation site system. Wikis are terrible for navigation, discovery, SEO, and content control.
Fedora migrated their guidelines out of the wiki last year[1][2] and Debian has always had theirs not in a wiki[3]. When Fedora moved, they were able to simplify their change control process to just "make a pull request and the packaging committee would review it". I'm not
Yeah, that idea also came to my mind too when I wrote those mails but then one thing at a time.. The challenge here might be that we do not really have a committee, even though some page lists some names. We do have a review team that needs to know the policies though. So would have to figure out who would be in charge of reviewing pull requests and how to sync with the review team in case both groups are distinct. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, HRB 36809 (AG Nürnberg), GF: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Fri, Jul 17, 2020 at 14:05, Ludwig Nussel <ludwig.nussel@suse.de> wrote:
Neal Gompa wrote:
[...] This brings up something that has been tickling at the back of my mind since it was discussed last year at SUSECON and oSC. We should strongly consider migrating our packaging guidelines *out* of the openSUSE Wiki into a documentation site system. Wikis are terrible for navigation, discovery, SEO, and content control.
Fedora migrated their guidelines out of the wiki last year[1][2] and Debian has always had theirs not in a wiki[3]. When Fedora moved, they were able to simplify their change control process to just "make a pull request and the packaging committee would review it". I'm not
Yeah, that idea also came to my mind too when I wrote those mails but then one thing at a time.. The challenge here might be that we do not really have a committee, even though some page lists some names. We do have a review team that needs to know the policies though. So would have to figure out who would be in charge of reviewing pull requests and how to sync with the review team in case both groups are distinct.
Since our current packaging documentation is a fork from Fedora guidelines from 2011, maybe we could collaborate with them on common documentation, which highlights differences when needed. LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 17. 7. 2020, at 14:12, Stasiek Michalski <hellcp@opensuse.org> wrote:
[...] This brings up something that has been tickling at the back of my mind since it was discussed last year at SUSECON and oSC. We should strongly consider migrating our packaging guidelines *out* of the openSUSE Wiki into a documentation site system. Wikis are terrible for navigation, discovery, SEO, and content control. Fedora migrated their guidelines out of the wiki last year[1][2] and Debian has always had theirs not in a wiki[3]. When Fedora moved, they were able to simplify their change control process to just "make a pull request and the packaging committee would review it". I'm not Yeah, that idea also came to my mind too when I wrote those mails but
On Fri, Jul 17, 2020 at 14:05, Ludwig Nussel <ludwig.nussel@suse.de> wrote: Neal Gompa wrote: then one thing at a time.. The challenge here might be that we do not really have a committee, even though some page lists some names. We do have a review team that needs to know the policies though. So would have to figure out who would be in charge of reviewing pull requests and how to sync with the review team in case both groups are distinct.
Since our current packaging documentation is a fork from Fedora guidelines from 2011, maybe we could collaborate with them on common documentation, which highlights differences when needed.
We could move it out onto git and make all contribs to go through pr. We should addd the review team as the people whom can merge stuff... If thats not enough ppl we could add bunch of packagers too... FWIW what pack team is doing we either automate the rules in spec-cleaner or add check s to rpmlint to actually stop and explain stuff by machine rather than relying on the human review to find something. With the rpmlint we actually go back by returning our rules and making them checked on fedora pkgs too... Tom
On Fri, 2020-07-17 at 14:11 +0200, Stasiek Michalski wrote:
On Fri, Jul 17, 2020 at 14:05, Ludwig Nussel <ludwig.nussel@suse.de> wrote:
Neal Gompa wrote:
[...] This brings up something that has been tickling at the back of my mind since it was discussed last year at SUSECON and oSC. We should strongly consider migrating our packaging guidelines *out* of the openSUSE Wiki into a documentation site system. Wikis are terrible for navigation, discovery, SEO, and content control.
Fedora migrated their guidelines out of the wiki last year[1][2] and Debian has always had theirs not in a wiki[3]. When Fedora moved, they were able to simplify their change control process to just "make a pull request and the packaging committee would review it". I'm not
Yeah, that idea also came to my mind too when I wrote those mails but then one thing at a time.. The challenge here might be that we do not really have a committee, even though some page lists some names. We do have a review team that needs to know the policies though. So would have to figure out who would be in charge of reviewing pull requests and how to sync with the review team in case both groups are distinct.
Since our current packaging documentation is a fork from Fedora guidelines from 2011, maybe we could collaborate with them on common documentation, which highlights differences when needed.
LCP [Stasiek] https://lcp.world Good idea, but I'd be still in favor of using SUSE's documentation build approach. Who'll talk to Fedora?
On Fri, Jul 17, 2020 at 9:01 AM Lubos Kocman <lubos.kocman@suse.com> wrote:
On Fri, 2020-07-17 at 14:11 +0200, Stasiek Michalski wrote:
On Fri, Jul 17, 2020 at 14:05, Ludwig Nussel <ludwig.nussel@suse.de> wrote:
Neal Gompa wrote:
[...] This brings up something that has been tickling at the back of my mind since it was discussed last year at SUSECON and oSC. We should strongly consider migrating our packaging guidelines *out* of the openSUSE Wiki into a documentation site system. Wikis are terrible for navigation, discovery, SEO, and content control.
Fedora migrated their guidelines out of the wiki last year[1][2] and Debian has always had theirs not in a wiki[3]. When Fedora moved, they were able to simplify their change control process to just "make a pull request and the packaging committee would review it". I'm not
Yeah, that idea also came to my mind too when I wrote those mails but then one thing at a time.. The challenge here might be that we do not really have a committee, even though some page lists some names. We do have a review team that needs to know the policies though. So would have to figure out who would be in charge of reviewing pull requests and how to sync with the review team in case both groups are distinct.
Since our current packaging documentation is a fork from Fedora guidelines from 2011, maybe we could collaborate with them on common documentation, which highlights differences when needed.
LCP [Stasiek] https://lcp.world Good idea, but I'd be still in favor of using SUSE's documentation build approach. Who'll talk to Fedora?
Stasiek has been doing most of our website build and content stuff lately, perhaps he can reach out to them. At least it should be easy enough to start the conversation by filing an issue: https://pagure.io/packaging-committee/issues -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Fri, 2020-07-17 at 15:01 +0200, Lubos Kocman wrote:
On Fri, 2020-07-17 at 14:11 +0200, Stasiek Michalski wrote:
On Fri, Jul 17, 2020 at 14:05, Ludwig Nussel <ludwig.nussel@suse.de
wrote:
Neal Gompa wrote:
[...] This brings up something that has been tickling at the back of my mind since it was discussed last year at SUSECON and oSC. We should strongly consider migrating our packaging guidelines *out* of the openSUSE Wiki into a documentation site system. Wikis are terrible for navigation, discovery, SEO, and content control.
Fedora migrated their guidelines out of the wiki last year[1][2] and Debian has always had theirs not in a wiki[3]. When Fedora moved, they were able to simplify their change control process to just "make a pull request and the packaging committee would review it". I'm not
Yeah, that idea also came to my mind too when I wrote those mails but then one thing at a time.. The challenge here might be that we do not really have a committee, even though some page lists some names. We do have a review team that needs to know the policies though. So would have to figure out who would be in charge of reviewing pull requests and how to sync with the review team in case both groups are distinct.
Since our current packaging documentation is a fork from Fedora guidelines from 2011, maybe we could collaborate with them on common documentation, which highlights differences when needed.
LCP [Stasiek] https://lcp.world Good idea, but I'd be still in favor of using SUSE's documentation build approach. Who'll talk to Fedora?
Btw if something I'd like to address also issues with nobody is taking care of various documentation requests inside component "Documentation". General statement from SUSE's documentation team is that they're working on release-notes (as this is what in the component represents) but not openSUSE wiki. So e.g. request to have a HDMI/Audio and other documentation requests rotting in the bugzilla. Having a traditional ascidoc style documents in git, could help us tackle this problem.
N�����r��y隊Z)z{.��ZrF��x>�{.n�+������Ǩ��r��i�m��0��ޙ������� ��$j���0�����Ǩ�
Hello openSUSE I just got back from vacation and haven't seen any progress on this one. Just to clarify did we all agree to move it out of wiki and co-op with Fedora? I suppose this is mainly questoin for Packaging TL Tomas. Lubos On Fri, 2020-07-17 at 13:01 +0000, Lubos Kocman wrote:
On Fri, 2020-07-17 at 14:11 +0200, Stasiek Michalski wrote:
On Fri, Jul 17, 2020 at 14:05, Ludwig Nussel <ludwig.nussel@suse.de
wrote:
Neal Gompa wrote:
[...] This brings up something that has been tickling at the back of my mind since it was discussed last year at SUSECON and oSC. We should strongly consider migrating our packaging guidelines *out* of the openSUSE Wiki into a documentation site system. Wikis are terrible for navigation, discovery, SEO, and content control.
Fedora migrated their guidelines out of the wiki last year[1][2] and Debian has always had theirs not in a wiki[3]. When Fedora moved, they were able to simplify their change control process to just "make a pull request and the packaging committee would review it". I'm not
Yeah, that idea also came to my mind too when I wrote those mails but then one thing at a time.. The challenge here might be that we do not really have a committee, even though some page lists some names. We do have a review team that needs to know the policies though. So would have to figure out who would be in charge of reviewing pull requests and how to sync with the review team in case both groups are distinct.
Since our current packaging documentation is a fork from Fedora guidelines from 2011, maybe we could collaborate with them on common documentation, which highlights differences when needed.
LCP [Stasiek] https://lcp.world Good idea, but I'd be still in favor of using SUSE's documentation build approach. Who'll talk to Fedora?
�{.n�+����������� ��$j��맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.��ZrF��x
� ޮ�^�ˬz� N�����r��y隊Z)z{.��ZrF��x>�{.n�+������Ǩ��r��i�m��0��ޙ������� ��$j���0�����Ǩ�
Neal Gompa <ngompa13@gmail.com> writes:
On Fri, Jul 17, 2020 at 7:34 AM Ludwig Nussel <ludwig.nussel@suse.de> wrote:
This brings up something that has been tickling at the back of my mind since it was discussed last year at SUSECON and oSC. We should strongly consider migrating our packaging guidelines *out* of the openSUSE Wiki into a documentation site system. Wikis are terrible for navigation, discovery, SEO, and content control.
Fedora migrated their guidelines out of the wiki last year[1][2] and Debian has always had theirs not in a wiki[3]. When Fedora moved, they were able to simplify their change control process to just "make a pull request and the packaging committee would review it". I'm not saying that we have to exactly replicate that process, but pulling it out of the wiki and using a docs system for documentation would be nice...
I'd definitely welcome having the guidelines outside of the wiki and people actually reviewing those. However, I really don't know who those reviewers should be, as currently every devel project has its own set of unwritten rules that only a handful of people really know. And then there would be the question where these guidelines should be put? Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer
On Friday 2020-07-17 14:10, Dan Čermák wrote:
This brings up something that has been tickling at the back of my mind since it was discussed last year at SUSECON and oSC. We should strongly consider migrating our packaging guidelines *out* of the openSUSE Wiki into a documentation site system.
However, I really don't know who those reviewers should be, as currently every devel project has its own set of unwritten rules
Devel projects can do whatever they want. The policy applies to packages in, or destined for, openSUSE:* . -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Jan Engelhardt <jengelh@inai.de> writes:
On Friday 2020-07-17 14:10, Dan Čermák wrote:
This brings up something that has been tickling at the back of my mind since it was discussed last year at SUSECON and oSC. We should strongly consider migrating our packaging guidelines *out* of the openSUSE Wiki into a documentation site system.
However, I really don't know who those reviewers should be, as currently every devel project has its own set of unwritten rules
Devel projects can do whatever they want.
The policy applies to packages in, or destined for, openSUSE:* .
And how do you get a package into openSUSE:*? Exactly, via devel project. What I mean by this is, that we have a bunch of conventions from devel projects, but these tend to be poorly documented in my experience. And these are of course carried over to openSUSE, even if the openSUSE reviewers don't care about them. This is not a problem per se, it just meanst that all devel project maintainers need to be involved, so that they don't start rejecting valid submissions according to the guidelines that the (currently hypothetical) packaging committee decided upon. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer
On Friday 2020-07-17 15:21, Dan Čermák wrote:
Jan Engelhardt <jengelh@inai.de> writes:
On Friday 2020-07-17 14:10, Dan Čermák wrote:
However, I really don't know who those reviewers should be, as currently every devel project has its own set of unwritten rules
Devel projects can do whatever they want. The policy applies to packages in, or destined for, openSUSE:* .
And how do you get a package into openSUSE:*? Exactly, via devel project.
which should imply that develprjs cannot meaningfully deviate from established conventions and have such unwritten rules, or else the package is susceptible to rejection.
we have a bunch of conventions from devel projects, but these tend to be poorly documented in my experience. And theseare of course carried over to openSUSE, even if the openSUSE reviewers don't care about them.
But that is a problem of the develprj('s documentation), not openSUSE:Factory. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Jan Engelhardt <jengelh@inai.de> writes:
On Friday 2020-07-17 15:21, Dan Čermák wrote:
Jan Engelhardt <jengelh@inai.de> writes:
On Friday 2020-07-17 14:10, Dan Čermák wrote:
However, I really don't know who those reviewers should be, as currently every devel project has its own set of unwritten rules
Devel projects can do whatever they want. The policy applies to packages in, or destined for, openSUSE:* .
And how do you get a package into openSUSE:*? Exactly, via devel project.
which should imply that develprjs cannot meaningfully deviate from established conventions and have such unwritten rules, or else the package is susceptible to rejection.
No, but they can have additional rules on top of that.
we have a bunch of conventions from devel projects, but these tend to be poorly documented in my experience. And theseare of course carried over to openSUSE, even if the openSUSE reviewers don't care about them.
But that is a problem of the develprj('s documentation), not openSUSE:Factory.
Yeah, but given the overall state of nearly any documentation, that's not really surprising. Anyway, I have not raised this point to throw dirt at specific maintainers but to make everyone aware that such a committee will have to either involve a lot of the devel project maintainers or be able to enforce its rules on them (including "no you can't make people do $xyz because we don't need such a rule"). Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer
On Fri, 2020-07-17 at 16:23 +0200, Dan Čermák wrote:
Anyway, I have not raised this point to throw dirt at specific maintainers but to make everyone aware that such a committee will have to either involve a lot of the devel project maintainers or be able to enforce its rules on them (including "no you can't make people do $xyz because we don't need such a rule").
A devel prj / pkg maintainer having MORE rules that are not conflicting with the openSUSE packaging guidelines must not be a problem. Some devel prjs just care more than others (which are mostly 'dumping grounds for not finding a better place'). In those collect-all-devel- prjs people usually are happy if stuff builds - and those devel PROJECTS are never treated as project, just as a collection of packages. People hardly verify that their submission does not break stuff even coming from the same devel prj there. It is rather an issue that a devel prj must not decline a package for a change that is mandatory to Factory. Add to that many devel prjs would be happy to have the bots run against their submissions too - nothing more annoying than getting a submission from *randomcontributor (which is nice), then see it rejceted when submitting to Factory (for valid reasons) - or having to run as pkg maintainer after a dozen build fallouts. Cheers, Dominique
On Friday 2020-07-17 16:23, Dan Čermák wrote:
[...] Such a committee will have to either involve a lot of the devel project maintainers or be able to enforce its rules on them (including "no you can't make people do $xyz because we don't need such a rule").
This starts to sound overly convoluted a process. Committee: Already exists - loosely but defacto, by way of any interested party chiming into ML discussions. Rule enforcement: Factory already upholds its rules (within its abilities), and devel:languages:python upholds rules (within their abilities) for their project. So this does not need change IMO. Don't need such rule: I currently see no reason why DLP should be forbidden to add rules {not conflicting with Factory} of their own. Think of it as federal law and state law. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Neal Gompa <ngompa13@gmail.com> writes:
On Fri, Jul 17, 2020 at 7:34 AM Ludwig Nussel <ludwig.nussel@suse.de> wrote:
This brings up something that has been tickling at the back of my mind since it was discussed last year at SUSECON and oSC. We should strongly consider migrating our packaging guidelines *out* of the openSUSE Wiki into a documentation site system. Wikis are terrible for navigation, discovery, SEO, and content control.
Fedora migrated their guidelines out of the wiki last year[1][2] and Debian has always had theirs not in a wiki[3]. When Fedora moved, they were able to simplify their change control process to just "make a pull request and the packaging committee would review it". I'm not saying that we have to exactly replicate that process, but pulling it out of the wiki and using a docs system for documentation would be nice...
I'd definitely welcome having the guidelines outside of the wiki and people actually reviewing those. However, I really don't know who those reviewers should be, as currently every devel project has its own set of unwritten rules that only a handful of people really know. And then there would be the question where these guidelines should be put? Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer
On 7/17/20 9:14 PM, Neal Gompa wrote:
On Fri, Jul 17, 2020 at 7:34 AM Ludwig Nussel <ludwig.nussel@suse.de> wrote:
Thorsten Kukuk wrote:
On Tue, Jul 14, Ludwig Nussel wrote:
Hi,
The section "(Build) Requirements" in
https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines#.28Build.29_Re...
is obsolete as rpm-build requires systemd-rpm-macros and the bcond is not relevant on current distros anymore.
Therefore I propose to remove the section without replacement.
In this regard, is the "BuildRequires: pkgconfig(systemd)" in the examples on that page really correct? For what do I need this BuildRequires if I package some sytemd units, but don't link against systemd?
I missed that but looks like you just changed it in the wiki. What's the point of the documented change process that I tried to follow here then if people just randomly modify the wiki?
This brings up something that has been tickling at the back of my mind since it was discussed last year at SUSECON and oSC. We should strongly consider migrating our packaging guidelines *out* of the openSUSE Wiki into a documentation site system. Wikis are terrible for navigation, discovery, SEO, and content control.
Fedora migrated their guidelines out of the wiki last year[1][2] and Debian has always had theirs not in a wiki[3]. When Fedora moved, they were able to simplify their change control process to just "make a pull request and the packaging committee would review it". I'm not saying that we have to exactly replicate that process, but pulling it out of the wiki and using a docs system for documentation would be nice...
I think an important part of any proposal would be that significant changes or changes that affect a large number of packages should still be discussed on the relevant mailing lists rather then in PR's or atleast that PR's for such proposals are posted to lists so people are aware rather then forcing everyone to try and subscribe to another place for discussion. Having said that most of our guidelines relate to specific groups and or languages and when proposals to those areas come in it should be a pretty quick process to accept them. -- 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
On Fri, Jul 17, Ludwig Nussel wrote:
What's the point of the documented change process that I tried to follow here then if people just randomly modify the wiki?
The change process is for changing guidelines, not for fixing a wrong example. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Thorsten Kukuk wrote:
On Fri, Jul 17, Ludwig Nussel wrote:
What's the point of the documented change process that I tried to follow here then if people just randomly modify the wiki?
The change process is for changing guidelines, not for fixing a wrong example.
The examples are part of the guidelines. Jan even claimed that the %{?systemd_odering} you suggested is pointless. So that deserves investigation before it spreads. Do zypp resp libsolv actually do anything with it? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, HRB 36809 (AG Nürnberg), GF: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Fri, Jul 17, Ludwig Nussel wrote:
Thorsten Kukuk wrote:
On Fri, Jul 17, Ludwig Nussel wrote:
What's the point of the documented change process that I tried to follow here then if people just randomly modify the wiki?
The change process is for changing guidelines, not for fixing a wrong example.
The examples are part of the guidelines. Jan even claimed that the %{?systemd_odering} you suggested is pointless. So that deserves investigation before it spreads.
Jans claim is wrong, he only need to read the RPM documentation. And he also wrote himself that this leaving systemd_ordering can lead to a broken system since systemd will ignore important new settings. Even if he thinks this can be ignored :( I don't think that risking that a service does not start correctly anymore after an update is acceptable and fits with a "rolling release". The real problem is, that we change, adjust and fix code, but nobody takes care to adjust the guidelines. So systemd should have never accepted in Factory with the new macros as they violate the guidelines?
Do zypp resp libsolv actually do anything with it?
If not it's a libsolv bug, RPM does something with it. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Friday 2020-07-17 14:45, Thorsten Kukuk wrote:
On Fri, Jul 17, Ludwig Nussel wrote:
Thorsten Kukuk wrote:
On Fri, Jul 17, Ludwig Nussel wrote:
What's the point of the documented change process that I tried to follow here then if people just randomly modify the wiki?
The change process is for changing guidelines, not for fixing a wrong example.
The examples are part of the guidelines. Jan even claimed that the %{?systemd_odering} you suggested is pointless. So that deserves investigation before it spreads.
[Claim being: "If $program depends on a particular systemd feature, it needs a versioned requires. In the absence of that, $program can get released to FTP sooner than system, at which point a "plea for ordering" does not do anything."]
Jans claim is wrong, he only need to read the RPM documentation. [...] If not it's a libsolv bug, RPM does something with it.
Why is the claim wrong? How the fuck is RPM supposed to do any ordering on systemd when systemd is not even given as an input to the rpm transaction? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Fri, Jul 17, Jan Engelhardt wrote:
Why is the claim wrong? How the fuck is RPM supposed to do any ordering on systemd when systemd is not even given as an input to the rpm transaction?
That was not my example. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, On Fri, 17 Jul 2020, Thorsten Kukuk wrote:
On Fri, Jul 17, Jan Engelhardt wrote:
Why is the claim wrong? How the fuck is RPM supposed to do any ordering on systemd when systemd is not even given as an input to the rpm transaction?
That was not my example.
That is true, Jan's claim doesn't affect your example. I think both points are valid and orthogonal, though. In your situation ($program and systemd being updated in the same transaction) you need the ordering requests, in his situation ($program available before systemd) you need the versioned requires. Both are required to be able to mindlessly update $program without risking a broken system, either by forcing the correct order or by forcing to accept an unfulfillable requires on an (in the situation still unavailable) versioned systemd. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Ludwig Nussel wrote:
Thorsten Kukuk wrote:
On Fri, Jul 17, Ludwig Nussel wrote:
What's the point of the documented change process that I tried to follow here then if people just randomly modify the wiki?
The change process is for changing guidelines, not for fixing a wrong example.
The examples are part of the guidelines. Jan even claimed that the %{?systemd_odering} you suggested is pointless. So that deserves investigation before it spreads. Do zypp resp libsolv actually do anything with it?
So according to mls libsolv does not support those ordering tags. Even if it would, it wouldn't have an effect as they are not in the metadata of the repo. So %systemd_ordering is pointless indeed right now. A simple "Suggests: systemd" would do the job instead apparently though. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, HRB 36809 (AG Nürnberg), GF: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Tue, Jul 14, Ludwig Nussel wrote:
Hi,
The section "(Build) Requirements" in https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines#.28Build.29_Re... is obsolete as rpm-build requires systemd-rpm-macros and the bcond is not relevant on current distros anymore.
Therefore I propose to remove the section without replacement.
By taking a deeper look at it: Assume we release a new Tumbleweed snapshot, which contains a new systemd version with new features, and adjusted other packages, which contain systemd units and make use of the new features. As we update with "zypper dup", we need to make sure, that systemd is updated before the other packages gets updated. Else the restart of the services will fail. So we should replace the section with: Requirements You should add: %{?systemd_odering} Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thursday 2020-07-16 09:36, Thorsten Kukuk wrote:
The section "(Build) Requirements" in https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines#.28Build.29_Re... is obsolete as rpm-build requires systemd-rpm-macros and the bcond is not relevant on current distros anymore.
Therefore I propose to remove the section without replacement.
As we update with "zypper dup", we need to make sure, that systemd is updated before the other packages gets updated. Else the restart of the services will fail.
So we should replace the section with:
Requirements You should add: %{?systemd_odering}
It's pointless. If $program depends on a particular systemd feature, it needs a versioned requires. In the absence of that, $program can get released to FTP sooner than system, at which point a "plea for ordering" does not do anything. I would also presume that unrecognized directives in .service units are non-fatal as well. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Ludwig Nussel wrote:
The section "(Build) Requirements" in
https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines#.28Build.29_Re...
is obsolete as rpm-build requires systemd-rpm-macros and the bcond is not relevant on current distros anymore.
Therefore I propose to remove the section without replacement.
Following the change process¹ the update will be applied if there are no strong objections within 14 days.
Meanwhile the page has been edited by different people without prior discussion. So I'd consider the request obsolete and the change process moot. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, HRB 36809 (AG Nürnberg), GF: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (11)
-
Dan Čermák -
Dominique Leuenberger / DimStar -
Jan Engelhardt -
Lubos Kocman -
Ludwig Nussel -
Michael Matz -
Neal Gompa -
Simon Lees -
Stasiek Michalski -
Thorsten Kukuk -
Tomas Chvatal