Problems with core review

[John Dennis]

On Thu, 2007-02-08 at 17:13 +0100, Michael Schwendt wrote:
> On Thu, 8 Feb 2007 10:28:21 -0500, Jesse Keating wrote:
> 
> > Clearly we need to have something in the guidelines about use of 
> > RPM_SOURCE_DIR or else this will come up over and over again.  However I lack 
> > the energy/time to push that through right now :/
> 
> The resistance you run into is a strong hint that the packaging committee
> ought to keep this issue out of the policies. Strong language doesn't help
> it. And you are right, the desire to force packagers into macro-madness
> and less readable spec files is "silly".

+1

Michael echos my sentiments eloquently. 

There is a lack of a consensus as well as a lack of clear technical
justification whose value trumps spec file readability.

I applaud the goal of spec file maintainability and robustness which is
the point of the review exercise, this is a good thing and I support it.
However what is being expressed is forcing the use of SOURCEn is not
necessarily in the service of that goal.

Jessie later wrote:

Jessie> Well, given that it is an rpmlint check, we should have wording
Jessie> on the wiki that explains why use of it is discouraged (can
Jessie> hurt builds from non-clean buildroots) and what forms of it are
Jessie> "acceptable".

It's presence in rpmlint is not a justification.

It is true with a non-clean build root you can shoot yourself in the
foot, but official builds never have that problem. In fact, if you don't
use build tools there are a myriad ways you can make mistakes. Do we
need a rule for every mistake one is capable of making outside the
defined build environment?

Let me give a further example, I'll call it "source collision". There is
nothing which prevents two independent packages from using a source file
with the same name. The basic default rpm macros do not enforce per
package source dirs, by default all packages share a common source dir.
One source rpm is capable of overwriting another source rpm's files if
they share a common name. There are only three ways to prevent this:

1) establish a rule which says every source file must be prepended with
a unique string (i.e. the package name).

2) always use per package source dirs.

3) always clear the src dir prior to building.

Options 2 & 3 are supported by build tools, if you use them you won't
have this problem.

If you don't use build tools you'll have to employ technique #1 and
enforce a rule with respect to unique names.

Thus because it's possible when not using build tools to have name
collisions producing a bad rpm. Are we now going to add a new rule?

"All source files must be prepended with their package name"

I doubt many people would agree that would be a wise and sensible rule
to enforce but it follows logically from the above argument over forced
use of $SOURCEn.

The point is the guidelines should be common sense for the majority of
situations and should not at the expense of the larger goal of
usable/maintainable spec files seek to close every possible potential
for undesired results. Readability and maintainability are more
important.

-- 
John Dennis <jdennis at redhat.com>