--- Comment #65 from Jan Pokorný <> ---
[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.:

> 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:

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:, hence can have upstream spec file
  almost arbitrarily complex, but that's just a source for further

- apply nifty tricks, which we did for instance in pacemaker to
  support %license tag also in EL6:

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 --
To unsubscribe send an email to

Reply via email to