Stop the git abuse

[Greg Swift]

On Mon, May 21, 2012 at 3:08 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> Greg Swift wrote:
>> i'm not against cleaning up ifs related to end of life/support
>> releases, but how far are you suggesting that go?
>
> All support for Fedora n should be dropped at Fedora n's end of life.

which fits within the definition I stated. okay.. np

>> I know that I've pulled plenty of rawhide packages for build on a RHEL box
>> when necessary, and even if they don't always support EPEL sometimes
>> they've had if switches in them that helped save me lots of time.
>
> We do not support this usecase. It is just not feasible to maintain so many
> conditionals in our packages. And Fedora version conditionals won't help you
> anyway if you're building for RHEL, you'd need RHEL version conditionals,
> which packages not supporting EPEL are very unlikely to contain.

So I recently helped bring python-augeas into EPEL.  Before that (for
the last 2+ years) the spec file supported RHEL conditionals and many
of the python-augeas users did local builds of the fedora package in
their RHEL environment.

Just because a package has not gotten an EPEL maintainer yet, doesn't
mean the package doesn't support RHEL.

The zabbix package is in EPEL.  On RHEL 5 that means it is in the 1.4
branch due to the update policies.  The Fedora package had gone
through 1.6 and 1.8 releases before RHEL6 came out, none of which are
in epel-testing. Myself and many others built our updated packages off
the fedora package. I know there are several other packages that fall
into this category.  So what would happen in those scenarios?

I realize that at some threshold maintaining too many conditionals can
make a spec very difficult to work with, but for very simple and
limited conditionals the same could be said of having multiple spec
files.  I'd really think that is more of a decision to be left to the
maintainer of the package since packages can vary so drastically.