https://bugzilla.redhat.com/show_bug.cgi?id=1507103 --- Comment #66 from Fabio Massimo Di Nitto <fdinitto@xxxxxxxxxx> --- (In reply to Jan Pokorný from comment #65) > [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 Not sure, we received the patch from the Suse maintainers, asking explicitly to enable it. Given that it didn´t affect Fedora I didn´t feel the need to investigate further. Probably the OBS is not the same as internal OpenSUSE build system? > > > 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. see below. > > > 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. the statement can be somehow interpreted: "To help facilitate legibility, only macros and conditionals for Fedora and EPEL are allowed to be used in Fedora Packages. Use of macros and conditionals for other distributions, including Fedora derivatives, is not permitted in spec files of packages in the main Fedora repositories unless those macros and conditionals are also present in Fedora." Then we can just change them to %if 0%{?fedora*..} but before answering, please read more below first. > > 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 The technicality on how to get there is an upstream problem, but ideally we will get the make $distro-specfile upstream to generate a valid (and policy compliant) spec file. One step at a time tho, once this is done, we can start merging things upstream for downstream benefit. -- 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
