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.ellson@xxxxxxxxxxx> 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 <mschwendt@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
