https://bugzilla.redhat.com/show_bug.cgi?id=1507103
--- Comment #65 from Jan Pokorný <jpokorny(a)redhat.com> ---
[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?exp...
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/a592019fbe88144bc42131b0e...
--
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