Update of the fish package

[Axel Liljencrantz]

On 8/1/06, Michael Schwendt <bugs.michael at gmx.net> wrote:
> On Tue, 1 Aug 2006 12:54:39 +0100, Jonathan Underwood wrote:
>
> > I guess we need some clarification here - is other distro stuff in the
> > spec file OK or not from a FE packaging perspective? FESCO?
>
> It boils down to a matter of perspective. If you confront a reviewer with
> an overloaded spec file, which fails to build _and_ contains several
> obvious mistakes, several pitfalls and questionable sections, it becomes
> obvious that the spec file complexity is the cause of maintenance
> difficulties and decreased readability. In such a scenario I also strongly
> encourage the packager to create a clean and easy-to-maintain spec file
> instead of trying to hit many nails at once with a single hammer.
>
> Often, such pseudo distribution-independent spec files become a mess and
> work for only a few of the target distributions, because some
> distribution-specific bugs and build problems remain and depend on
> contributed fixes. In particular, when the packager does not have access
> to all the supported dists.
>
> Spec files for multiple distribution also result in superfluous changes (=
> the packager trying to sync spec files without reason), which bear the risk
> of breaking things by accident.
>
> The more you think about it and the more you practise it, the more you
> will like distribution-specific spec files. A single spec file for each
> distribution. Incremental changes, small changes. And for many version
> upgrades, you only need to touch Source, %version, %release and nothing
> else.

All the things you say are probably true and valid counterpoints to
the arguments made by myself and others advocating a single spec-file.
But I don't think your points always apply. If you look at e.g. the
spec file of fish, it is rather short and simple, even with the recent
additions:

http://roo.no-ip.org/fish/darcs/fish.spec

The only part of the spec that is distribution specific is the
BuildRequires to bring in the X headers. I would say that in such
simple cases, the advantages of a single spec file are larger than the
advantage of a slightly simpler file. But e.g. the spec file for the
Courier package discussed in the thread referenced in one of the
previous posts is a lot more complicated, and I wouldn't presume to
know if writing a fedora-specific spec-file would be better.

To me, it seems that advocating always using the same approach to
writing spec-files ignores the fact that some packages are a great
deal more complicated than others. I would think trusting the common
sense of the maintainers to make the right choice in individual cases
instead of imposing a one size fits all solution makes the most sense.

-- 
Axel