Hi,
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.
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.
- 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?).
On 05/20/2009 02:39 PM, Jussi Lehtola 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.
They're not incorrect, so while I personally agree that these are generally unnecessary, I'm not sure it merits a ban.
~spot
On 05/20/2009 11:39 AM, Jussi Lehtola wrote:
Hi,
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.
They're unnecessary but not wrong and they don't obscure the meaning very much. I would be against having a ban in the Guidelines since it's adding something to the packager workload and another Guideline to have to look at when searching for what you really want for not much gain.
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.
- 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?).
If you're interested in working on the coding for such a tool (or can find someone who is), I once worked on qa-assistant http://developer.berlios.de/projects/qa-assistant/
But I didn't have time for it anymore so I'd be happy to give someone interested in it access.
Also, there's several command line tools out there that do automated checking (as opposed to creating a checklist). Those might be a better use of time to work on.
-Toshio
On Wed, 20 May 2009 21:39:31 +0300 Jussi Lehtola jussilehtola@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.
On Wednesday, May 20 2009, Tom spot Callaway said:
On 05/20/2009 02:39 PM, Jussi Lehtola 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.
They're not incorrect, so while I personally agree that these are generally unnecessary, I'm not sure it merits a ban.
And really, if we don't want them being used, then we should just not have them defined as rpm macros IMHO
Jeremy
packaging@lists.fedoraproject.org