Dne 13.3.2013 13:12, Vít Ondruch napsal(a):
Hi,
Wouldn't it be possible to have packaging guidelines versioned by
Fedora version? If this would be accompanied by the rule, that .spec
files can't be shared as well (using some conditions), this would
allow us to have much faster evolution of our packaging. I'll give you
a few examples.
= Tilde versioning
It is available in RPM since 4.10 [1], i.e. Fedora 18. It is
prohibited by guidelines [2].
= Support for /usr/lib/rpm/macros.d/
Available since RPM 4.11 [3, 4], i.e. Fedora 19, nobody place the
additional macros there (well I'll fix Ruby and RubyGems as soon as
I'll have some free cycles). Actually it could be nice scripted.
= Changes in Ruby guidelines
There are currently 3 versions of Ruby guidelines [5], which apply to
different versions of Fedora and EPEL anyway.
= %clean section
Not mandated since F13 [6], but widely used in older packages. That
could be easily removed by script it there would not be chance that
the package is in use for EPEL5
= BuildRoot tag
Not needed since F10! [7] But needed by EPEL. BTW you should not
update packages in EPEL, to keep ABI stability, anyway, so why you
should carry around such thing in F20? There is high chance that EPEL5
package contains much older version.
= mandatory %defattr at the beginning of %files section
Not needed since RPM 4.4 [8].
This is not exhaustive list. If you just count %clean section,
BuildRoot tag and %deffattr, the spec file could be 5 lines shorter. 5
lines which can make difference in maintainability, in attraction new
packagers, since they would not need to wonder "what the BuildRoot is
there for?"
What I have learned during recent rebuild of Ruby packages is that the
.specs, which contains conditions to support different versions of
Fedora or EPEL are the one, which are the hardest to maintain. There
is no simple way how to automatically migrate them to support newer
guidelines. This exactly prohibits the innovation. This prohibits any
new feature which we could benefit.
If the .spec would be specific to the Fedora version, it could follow
the latest and greatest development. However there are some version
specific branches which prevent that.
Some may object, that the resulting binary RPM should be compatible
between Fedoras and installable everywhere, but I can assure you, that
you cannot install any RPM which depends on Ruby from F18 to F19 and
vice versa, so the argument is moot. This apply also to all libraries
after soname bump, not just that we are doing something terribly wrong
in Ruby.
So please, consider this proposal. In a long term (speaking about
really long term now), the .spec file should contain just a few lines,
such as SOURCE0 and the rest would be done by a few simple macros.
Take a look for example what Java guys did recently [9] and how it
used to be [10] (I am sure they could provide you better examples :).
This would let us to focus on more important things then copy pasting
guidelines to .spec files.
One more point, there is not visible on the first look what version of
Fedora/EPEL the .spec file targets. Shall I do the modifications or not?
Although I could do them, I will not, since I am unsure. It needs to
check all branches and you still might be wrong what was the intention
of maintainer.
Vít
Thank you
Vít
[1] http://www.rpm.org/wiki/Releases/4.10.0
[2] http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Version_Tag
[3] http://www.rpm.org/wiki/Releases/4.11.0
[4] https://bugzilla.redhat.com/show_bug.cgi?id=846679
[5] https://fedoraproject.org/wiki/Packaging:Ruby
[6] https://fedoraproject.org/wiki/Packaging:Guidelines#.25clean
[7] https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRoot_tag
[8] https://fedoraproject.org/wiki/Packaging:Guidelines#File_Permissions
[9] https://fedoraproject.org/wiki/Packaging:Java#Apache_Maven
[10]
https://fedoraproject.org/w/index.php?title=Packaging:Java&oldid=246507#maven2
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging
