Hi,
Regarding this ticket https://pagure.io/fesco/issue/1909 I am opening a ticket here as well. Would it be possible to discuss this proposal and provide us with a decision?
lately, we unified upstream spec files with the downstream ones to make releases of all ABRT's packages much easier for maintainers. Due to this rule in [1], we would like to ask for an exception to be able to have SUSE related conditions in the downstream spec file. Is it possible to have %{?suse_version} condition in the downstream spec files or should I remove them? Regards Matej [1] https://fedoraproject.org/wiki/Packaging:Guidelines#Spec_Legibility ... AGREED: Defer to FPC, but indicate that FESCo suggests that the "readibility" guidelines can be relaxed. (+7, 0, -0) To clarify that a bit, FESCo has established the Fedora Packaging Committee (FPC) to make packaging guidelines, and we feel this decision is best left to them. FESCo believes that the readability guidelines can be relaxed, but ultimately leaves that decision to the FPC since they were established for that purpose.
Could you please link your spec file(s)? If it doesn't pollute spec files much -- +1 from me.
https://github.com/abrt/abrt/blob/master/abrt.spec.in https://github.com/abrt/libreport/blob/master/libreport.spec.in https://github.com/abrt/satyr/blob/master/satyr.spec.in
I really don't get the desire to maintain an universal horrible spec upstream instead of having multiple clean specfiles, but I guess that's your decision and one more conditional won't make a big difference.
This is a bitter +1 from me.
-1 from me. The farthest I'd go is "we prefer that you not do this and aren't going to change existing guidelines to explicitly allow it, but we can't stop you".
Some observations:
You're already preprocessing the spec, which means that not only do you not really need this since you could just do it in your preprocessing step, but you're also most likely violating https://fedoraproject.org/wiki/Packaging:Guidelines#Spec_Maintenance_and_Canonicity. What happens if someone makes a tweak to the specfile in Fedora? Do you just copy over their changes?
The reason we prohibit this kind of thing (and have the above-linked guideline) is because we expect that all packages in the distribution will be maintained by the community of maintainers within the src.fedoraproject.org git repository. We already expect maintainers to know a lot; we can't require them to know what things are required on SuSE as well. Seeing that in a specfile just means it's another one that I (and probably most packagers) can't or won't want to touch because they have no way to test things.
To me looking at the above-linked unpreprocessed specfiles objectively, the satyr one doesn't look too bad, really. The abrt one kind of crosses the line of "doesn't pollute the spec".
I wonder if some maintainers (in either Fedora or SuSE or in an idea world both) would be willing to add some Provides: to a few key packages so that you could have a consistent set of dependencies on both distros. Obviously doing this generally would be a big effort, but for abrt's purposes you could get by with just a few.
Metadata Update from @tibbs: - Issue tagged with: meeting
(Note that the abrt people were very responsive to my src.fp.o PRs and they never told me: "No, do an upstream PR instead", but they rather incorporated my changes to their upstream. This is not true for other kind of projects we have in Fedora unfortunately, but with abrt, it was always a pleasant experience.)
I said this in the original fesco ticket, but since there's now an FPC ticket, I'll mention it here too...
For what it's worth, while I very much prefer readable packaging, as a package maintainer for software across multiple RPM based distributions (Fedora, RHEL/CentOS, Mageia, openSUSE, et al), it'd be way nicer if I could leverage the same spec everywhere.
However, I think if we allow it, we should absolutely document how these conditionals work, similar to what openSUSE has in their guidelines (though a bit more up to date... Mandriva is dead, after all...).
I do get what @tibbs is saying, and I'd like to address a few of his points specifically:
Generally speaking, in Mageia and openSUSE, we're open to adding bits and pieces where we can to offer something like common package Provides so that we can minimize ugliness and maximize distro portability for spec files. Obviously, it's easier in Mageia due to common heritage with Fedora, but openSUSE does it too from time to time.
It would be nice if we could work together on improving this, too, since it simplifies the number of cases where it's needed.
At least in my case, I try to minimize and logically arrange things so that cross-distro specs aren't uglier than a distro-specific one. There are some cases where I can't manage it, and at that point, I just split them into distro-specific ones.
We already expect maintainers to know a lot; we can't require them to know what things are required on SuSE as well. Seeing that in a specfile just means it's another one that I (and probably most packagers) can't or won't want to touch because they have no way to test things.
It helps that Fedora, Mageia, and openSUSE are broadly compatible with each other and it's possible to test and build for all three with mock and publish with COPR. So insofar as testing things, it's doable nowadays if anyone wants to. I certainly do it with most of my packages.
Thankfully, distribution differences have been slowly falling away over the years, but there are still differences. But things like common provides, autogenerated names from dep generators, etc. help with this considerably, and everyone has an incentive to move towards those in the RPM ecosystem.
It looks like you are pretty ok with this. I close this ticket if there isn't a complaint by a week.
It looks like you are pretty ok with this
What?
I find it difficult to think anyone could possibly interpret my previous comments as being "pretty OK with this". The two characters in the comment are "-1".
It looks like you are pretty ok with this.
If you count "we can't really stop you if you desperately want to do this, despite our concerns" as being "pretty ok" ... well, then yes.
I didn't want to sound harsh. I just wanted to push this ticket toward resolving.
We talked about this in this weeks meeting (https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2018-10-04/fpc.2018-10-04-16.00.txt):
Metadata Update from @james: - Issue close_status updated to: nothingtodo - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.