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

Re: Update of the fish package

On 8/1/06, Michael Schwendt <bugs michael 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

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


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.


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