On 30 November 2017 at 03:49, Vít Ondruch <vondruch(a)redhat.com> wrote:
Reading logs from yesterdays FPC meeting , I think we should discuss
what is actually purpose of packaging guidelines and which version of
Fedora/EPEL/RHEL they actually targets.
Apparently, there are two camps of packagers in Fedora/EPEL. Those who want:
1) single version of .spec file to cover the whole Red Hat ecosystem.
2) clean .spec file following the latest and greatest packaging practices.
I personally belong to the group (2) and that is for several reasons:
a) I use Rawhide on daily basis and I develop only for Rawhide. If I do
changes in older Fedoras, then it is typically just bug fixes and
honestly, that does not happen often (I am POC of ~200 packages and I
submitted just 40 updates during last year ). And in fact, this is
official philosophy of updates , not just mine.
b) I spent time developing features which should simplify packaging (for
example in F27+, the RPM %setup macro can expand the .gem packages) and
I want to use these technologies to simplify my life and life of others.
c) As a proven packager and person who typically does rebuild of Ruby
packages, I really hate the branched .spec files where nobody knows what
was the purpose of the branches, most of the branches are for obsolete
and unsupported releases etc. It is quite hard to apply any improvements
into such packages. Moreover it is not realistic to test them. If they
were maintained, it would be different story, but the reality is different.
Don't get me wrong, I understand that there are packagers who has just
handful of packages and it is better for them to maintain just single
.spec file with all the branches and I don't mind them as long as the
packages are really actively maintained. But this approach just don't
scale and should be exception and not recommended practice.
To sum this up, my take on packaging guidelines is that *the guidelines
should document the most recent practices available in Rawhide and this
should be documented*. Covering all the exceptions necessary for older
Fedoras (not even mentioning RHEL/EPEL) makes the guidelines unreadable
and what is worse, they slow down entire development of Fedora.
Honestly, I think the RHEL/EPEL part of your conversation is a Red
Herring (aka not the real point).
You are wanting people to follow your method of packaging everything
because it makes your job easier. The problem is that other packagers
want you to follow their method and that makes your job harder. EPEL
versions stand out like a sore thumb of wanting that but even the
differences between getting something working in F25 and F28 can be
quite a bunch of %if strings which makes your job harder. On the other
hand, other people aren't interested in Rawhide and want all that.
The problem is an age old one and one that comes up after every couple
of releases. I think the EPEL group have tried a lot of different
solutions which try to help on this
1. If a package is not maintainable to the developer, stop maintaining
it. At the moment, it will be removed from usage. People wanting it
can get it from various archives.
2. Tibbs has gone through several herculian efforts to backport as
much of the new FPC macros and such to older EPEL's so that newer
schemes can work.
3. We are open to suggestions of what maintainers and developers want
or do not want out of the repository.
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Stephen J Smoogen.