https://bugzilla.redhat.com/show_bug.cgi?id=1507103 --- Comment #65 from Jan Pokorný <jpokorny@xxxxxxxxxx> --- [re A.] > The debuginfo generation is default: on in fedora. Those statements > have no effect on fedora unless explicitly overridden. Those are > coming from upstream spec file that requires tuning to build debuginfo > on Opensuse. Can you enlighten me, then, how OpenSUSE and their OBS perhaps relate to the need to specify "debug_package" macro explicitly? I was unable to find such instructions, and the spec-s I looked at did not need it, either, e.g.: https://build.opensuse.org/package/view_file/devel:gcc/gcc8/gcc8.spec?expand=1 > They create no harm and have no effect on Fedora. The end result is > the same. I am not disputing direct effects, just the spec file clarity important for comprehension by arbitrary Fedora maintainers, per the linked statement in the guidelines: https://fedoraproject.org/wiki/Packaging:Guidelines#Spec_Legibility Anything not a concern of Fedora doesn't belong to a dedicated specfile. > Something you missed in the process is that as the review goes, we are > merging all those bits back into upstream spec file so that it can > build properly both for suse and fedora / rhel / centos and reduce the > need to maintain multiple spec files around (after all as you somehow > agreed below in another context we want to kill redundancy). > > Given that those are more useful on opensuse we can add a: > %if 0%{?suse_version} > somewhere later on to make them even more transparent for fedora. This is expressly forbidden, see the link. Therein lies a clear conflict of interest: - upstream: one-size-fits-all should it be interested in high-level packaging at all - downstream: well-tailored solution, following special needs and conventions of the distribution for its greater good Solution may be a mix of: - use conditionalized spec in upstream, drop irrelevant conditionals when reflecting the upstream changes in downstream - maintain downstream-quality spec files in upstream as discrete files per distro - synthesis of the previous two can be to use a macro language like M4 to conditionalize without spoiling the results (for clufter, I abused the fact that spec language is in itself based on expanding macros, which can be selectively blinded with external preprocessing: https://pagure.io/distill-spec, hence can have upstream spec file almost arbitrarily complex, but that's just a source for further chewing: https://pagure.io/clufter/blob/master/f/misc/clufter.spec) - apply nifty tricks, which we did for instance in pacemaker to support %license tag also in EL6: https://github.com/ClusterLabs/pacemaker/commit/a592019fbe88144bc42131b0e20deea96acd6d45 -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx
