On Wed, Jul 15, 2020 at 5:56 AM Jan Engelhardt 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

On Fri, Jul 17, 2020 at 7:34 AM Ludwig Nussel 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

On Fri, Jul 17, 2020 at 14:05, Ludwig Nussel 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 Fri, 2020-07-17 at 14:11 +0200, Stasiek Michalski wrote:

On Fri, Jul 17, 2020 at 14:05, Ludwig Nussel 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, 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

...

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�����Ǩ�

Neal Gompa writes:

On Fri, Jul 17, 2020 at 7:34 AM Ludwig Nussel 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 Software Engineer Development tools SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer

Jan Engelhardt 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 Software Engineer Development tools SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer

Jan Engelhardt writes:

On Friday 2020-07-17 15:21, Dan Čermák wrote:

...

Jan Engelhardt 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 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 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

On 7/17/20 9:14 PM, Neal Gompa wrote:

On Fri, Jul 17, 2020 at 7:34 AM Ludwig Nussel 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

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 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

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