On Wed, 20 May 2009 21:39:31 +0300
Jussi Lehtola <jussilehtola@xxxxxxxxxxxxxxxxx> 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.
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
