On 8/1/06, Jesse Keating <jkeating@xxxxxxxxxx> wrote:
On Tuesday 01 August 2006 07:43, Laurent Rineau wrote: > I don't understand the point. As an upstream developper of CGAL¹, for > example, I would prefere that the spec file for Fedora is the same as the > one we use internally to generate development snapshots. Yes the resulting > spec file is quite an advanced one, because of that. But if I can prove > that I have written it, and can maintain it, what is the problem, from the > FE point of view? The resulting RPMs are not bloated because of the > complexity of the src.rpm file. Because when a security flaw comes around and you're not there to fix it, somebody else has to be able to understand your spec and be able to massage a patch into it. Ditto for a forced rebuild, or for any number of things. This is a community project, you have to think in terms of somebody else being able to maintain your spec file, so you'll want to make it as easy as possible for somebody to do this, and that means clean as possible specs and as less complicated as possible.
Look at e.g. http://roo.no-ip.org/fish/darcs/fish.spec can you honestly say that 'nobody could understand the spec'? Also, keep in mind that by using one spec file in stead of many, you only need to fix e.g. a security problem once in stead of once per major version of every supported operating system. My point is that in stead of saying 'never use generic .spec files' or 'never include anything not fedora-related in a .spec file', a more forgiving guideline like 'do not include anything not fedora-related in an already complex .spec file, and whenever possible, keep .spec files simple' is preferable. While the former is much easier to enforce, I feel that using such broad strokes in the guidelines will create a lot of extra work for people with simple packages, e.g. me.
-- Jesse Keating Release Engineer: Fedora
-- Axel -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
