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@xxxxxxxxxx> -- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
