I've limited the upstream .spec to el >= 6 and fc >= 23, and then removed a lot of conditionals that are no longer needed (with some loss of generality).
Latest upstream spec (pre-configure source) is at: https://github.com/ellson/graphviz/blob/master/graphviz.spec.in and the resulting source rpm is at http://graphviz.org/pub/graphviz/development/SRPMS/graphviz-2.41.20170720.1642-1.src.rpm > On July 20, 2017 at 9:36 AM John Ellson <john.ell...@comcast.net> wrote: > > > Doubtful. It's a maintenance nightmare > OK, but I'm raising this issue to try to get some help on getting a > little closer. > > > Tons of defines and conditionals, which toggle almost everything (BR, > features and subpkgs) > Yes,as a means of stating which feature can be built for which distro. > This are determined by the available packages from the distro. I do not > arbitrarily > turn them on or off. If a dependency becomes available, then I can turn > the define on, but in that transition nothing is obsoleted. > > > using highly cryptic macro names, > > sections that don't adhere to the packaging guidelines, > > dangerous violations of the guidelines, > > Specific examples please? > > > workarounds for RHEL 7. > Actually there are no workarounds for RHEL7. RHEL7 and RHEL6 package sets > are the same. > There are workarounds for RHEL4 and RHEL5, but at this point those could > all be purged from the spec. > > There are also workarounds for Fedora <23. Removing those as well would > simplify the spec considerably. I am willing to do that. > > > You may be familiar with the spec file, or you may believe you are, but > in my point of view, the spec file is filled with pitfalls. That will > backfire eventually. > Well, this is why I'm asking for help. > > > Not even the %changelog has been maintained since 2009. > Guilty. > > > And probably the biggest mistake related to conditional subpackage > builds is that you cannot simply flip a #define and disable a subpackage > build without inserting an Obsoletes/Provides pair. > As discussed, they are not used in that way. They have been only used to > not-enable a feature or subpackage on distros that don't provide the needed > dependencies. > > > So, what may be of some limited use while testing builds, is of no use > in packages released into a public distribution. > So as I understand it, you would like a separate .spec file for each > distro, to avoid the #define. ? > Can we agree to differ on that issue between upstream and public > distribution, for now? Can we work on the other issues first? > > John > > > On July 20, 2017 at 6:47 AM Michael Schwendt <mschwe...@gmail.com> > wrote: > > > > > > On Wed, 19 Jul 2017 13:27:54 -0400 (EDT), John Ellson wrote: > > > > > Jaroslav Škarvada requested that i move the discussion from: > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1410366 > > > > > > about unifying the graphviz .spec file with upstream, to this list. > > > > > > > > > Perhaps the unification objective is not attainable because of > different requirements? > > > > > > > > > Upstream, we have single a distro-agnostic (RH and non-RH) > graphviz.tar.gz portable sources: > > > > > > http://graphviz.org/Download_source.php > > > > > > and then for RH, all distros, we have a single graphviz.src.rpm > containing a universal graphviz.spec. > > > > > > http://graphviz.org/Download_linux_fedora.php > > > > > > > > > This works well for me, upstream, for building and testing across all > distributions, but perhaps the .spec file is less optimal when you separately > maintain versions for each distribution? > > > > > > > Doubtful. It's a maintenance nightmare. Tons of defines and > conditionals, > > which toggle almost everything (BR, features and subpkgs) using highly > > cryptic macro names, sections that don't adhere to the packaging > > guidelines, dangerous violations of the guidelines, workarounds for RHEL > > 7. You may be familiar with the spec file, or you may believe you are, > but > > in my point of view, the spec file is filled with pitfalls. That will > > backfire eventually. Not even the %changelog has been maintained since > > 2009. And probably the biggest mistake related to conditional subpackage > > builds is that you cannot simply flip a #define and disable a subpackage > > build without inserting an Obsoletes/Provides pair. So, what may be of > > some limited use while testing builds, is of no use in packages released > > into a public distribution. > > _______________________________________________ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
