Re: RFD Unifying graphviz.spec with upstream

[Vít Ondruch]

Dne 21.7.2017 v 00:24 David Sommerseth napsal(a):
> On 20/07/17 12:47, Michael Schwendt wrote:
>> On Wed, 19 Jul 2017 13:27:54 -0400 (EDT), John Ellson wrote:
>>> 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.
> I second this opinion.  We've had a similar discussion within the
> upstream OpenVPN team as well.  Most distributions have their own
> tracking of the .spec files, with their own set of packaging guidelines
> and preferences how things should do.  Yes, it is possible to use %if to
> get around all that.  But the end result in the .spec file is much
> harder to read and follow.
>
> I recommend to let distributions be distributions, and let each
> distribution carry their own .spec file - especially targeting their
> needs and processes.  The benefit of carrying a unified .spec file is
> really not worth the efforts in the long run IMO.

There is also this policy:

https://fedoraproject.org/wiki/Packaging:Guidelines#Spec_Maintenance_and_Canonicity

Vít
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFD Unifying graphviz.spec with upstream

[David Sommerseth]

On 20/07/17 12:47, Michael Schwendt wrote:
> On Wed, 19 Jul 2017 13:27:54 -0400 (EDT), John Ellson wrote:
>>
>> 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.

I second this opinion.  We've had a similar discussion within the
upstream OpenVPN team as well.  Most distributions have their own
tracking of the .spec files, with their own set of packaging guidelines
and preferences how things should do.  Yes, it is possible to use %if to
get around all that.  But the end result in the .spec file is much
harder to read and follow.

I recommend to let distributions be distributions, and let each
distribution carry their own .spec file - especially targeting their
needs and processes.  The benefit of carrying a unified .spec file is
really not worth the efforts in the long run IMO.

Once the RPM build tools and packaging guidelines is unified across all
RPM based distributions you will find it reasonable to unify the .spec
files.


-- 
kind regards,

David Sommerseth
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFD Unifying graphviz.spec with upstream

[Michael Schwendt]

On Thu, 20 Jul 2017 09:36:10 -0400 (EDT), John Ellson wrote:

> Specific examples please?

Non-versioned Obsoletes as one example. Arch-independent explicit Requires
as another example.

When is the last time you've run the fedora-review tool on this src.rpm?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFD Unifying graphviz.spec with upstream

[John Ellson]

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

> 

Re: RFD Unifying graphviz.spec with upstream

[John Ellson]

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

Re: RFD Unifying graphviz.spec with upstream

[Michael Schwendt]

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