https://bugzilla.redhat.com/show_bug.cgi?id=1507103



--- Comment #65 from Jan Pokorný <jpoko...@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?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@lists.fedoraproject.org
To unsubscribe send an email to package-review-le...@lists.fedoraproject.org

Reply via email to