On 8/1/06, Michael Schwendt <bugs.michael@xxxxxxx> 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 -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
