On Wed, 20 May 2009 21:39:31 +0300
Jussi Lehtola <jussilehtola(a)fedoraproject.org> wrote:
First: should we have a policy of using macros for standard
commands?
RPM includes standard macros such as %{__mv}, %{__rm}, %{__mkdir},
%{__cp}, %{__python}, %{__perl} and so on, which are used by some
people.
I find that the use of these macros unnecessarily obscures the spec
file and thus would like to have the ban on these as part of the
Packaging Guidelines.
I don't find them problematic in this way, especially not for the
examples cited above, which all start with __ and hence the underlying
commands all line up nicely with each other when you have a sequence of
these commands in a spec file, and hence is perfectly readable IMHO.
Second, a packager's / reviewer's software wishlist:
- Is there some tool to check out the redundancy of Requires and
BuildRequires? If not, it should be quite trivial to code, since all
the tool would need to do is pull the full requirement tree for each
R and BR and crosscheck whether there is overlap.
Of course, I would do this myself but I'm not as familiar as I should
be with a) python, b) yum bindings or c) GUI programming to code such
a thing.
I don't think this is a good idea as determining the correct set of
buildrequires isn't easily automatable.
For instance, suppose we have a package P that uses two libraries, L1 &
L2. And suppose that library L1 internally uses L2 and hence L1-devel
requires L2-devel. A packager might well submit a package for P that
buildrequires L1-devel and L2-devel (which would in fact be the right
thing to do, since P actually uses these libraries directly). However,
a naïve application of a buildreq redundancy finding tool would suggest
that P's buildreq of L2-devel was redundant, and the packager might
accept that finding and remove it. All would be well until some time
down the line when a new version of L1 came along that was built on a
different underlying library L3 rather than L2, and so L1-devel changed
its dependency of L2-devel to L3-devel. A new build of P would then
fail because L2-devel wouldn't get pulled in.
- Also a some kind of review helper tool would be nice. This should
have preferably (skeleton) input files in text for different types of
reviews: C libraries, python modules etc could all have a customized
review checklist.
The tool would then present the GUI checklist formed from the skeleton
input file, with a tab of possible resolutions (e.g. OK, NEEDSWORK,
N/A, ?) and a comment text box for each item.
The output could be saved to a text file and pasted into the review in
BZ (or the tool could even have a direct connection with BZ?).
That would be nice, yes, though you'd still want a full review
checklist being available for things like library packages that provide
bindings for multiple languages and don't fit nicely into a single
language checklist.
Paul.