Dne 13.3.2013 18:01, Ralf Corsepius napsal(a):
On 03/13/2013 04:20 PM, Vít Ondruch wrote:
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].
-1 Any changes to NEVR conventions are dangerous. They need to be
supported by all rpm-related tools and all active versions of Fedora.
Wrong, if the guidelines would be version specific, it would be obvious
that you can start using this functionality for F18. Yes, you can hit
issues if you try on F17, but it was never intended to work on older
releases, so that is not surprise.
I.e. I don't see much sense in allowing tilde before all rpm-related
tools in Fedora have been tested for supporting this and before all
Fedoras' rpms support it (I.e. not before f17 went EOL).
Yes, testing is definitely needed, but it has nothing to do with f17 EOL.
= 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.
-1 Too late for f19.
There is never too late. For Ruby for example, it means to test 3
packages at most. This will make no harm even in the middle of F19
lifecycle.
Try to propose this as a feature for f20.
Actually this is not bad idea, thank you for suggestion.
= %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
-1 %clean doesn't do any harm
Yes, we both know that, but it does not help anything as well, so why it
should be there? It is just bloat.
=> No need for action. Can be grandfathered.
= 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.
Because specs might be shared?
I shown in other thread that the "shared" .spec is not reality. Now even
spec for F18 and F19 differs even if you did not touch them, since there
was mass rebuild and spec has different revisions and changelog entries.
= mandatory %defattr at the beginning of %files section
Not needed since RPM 4.4 [8].
-1 %clean doesn't harm => No need for action. Can be
grandfathered/ignored.
Copy/paste mistake? :) Should I copy/paste my answer as well? ;)
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.
There is no rule prohibiting maintainers from doing so. It's up to a
package's maintainer's discretion.
Yes there is no, that is why this thread started. Limited sharing =>
greater innovation of our packaging => less work for new packages as
well as less learning for newcoming packagers, less possibility for error.
Vít
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging
