[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Update of the fish package



On 8/1/06, Jesse Keating <jkeating redhat com> 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]