On Fri, 09 Jan 2004 16:57:34 -0500, Karl DeBisschop wrote:
But back to generic packages as described by me roughly, find someone who's willing to review them on a low level. It really is no fun to spend time on something which looks unnecessary. We build for Fedora Core (and Red Hat Linux) only, not for Distribution ABC which requires different packaging and which uses additional helper tools.
Somehow it seems to me contrary to the idea that Fedora stresses upstream bugfixes.
I fail to see the connection between a spec file mess and integrating bug-fixes upstream.
The connection is that I see an application that requires a mess to package as broken. That brokenness should ideally be communicated upstream so the developer can address if for the benefit of all distros. When a packager's first choice is to create that spec file mess, rather than work the developer to avoid it, the community as a whole is being shortchanged.
I've killed some quotes deliberately because they haven't help in avoiding a misunderstanding. In my original comment on "generic packages" I refer to spec files which attempt at getting it right for more than a specific distribution. With "spec file mess" I refer to them using lots of %define constants or macros to be set manually, lots of conditional code to do some things differently for different distributions and an additional multitude of conditional %_with/%_without checks to build the package in a variety of configurations. While the latter may be useful for some users, the rest is just bloat, a "mess" that is not fun to review, especially not when patches are bzipped or if conditional code is also in %post scriplets [and calls distribution-specific helper tools] and if it takes extra effort to see *how* the software is built.
Apart from that, not everything you ship upstream is included.
I don't see what you're getting at here. But I think we're more in agreement than I thought at first, so it may not be worth dragging out.
Patches, patches, patches, but also packaging style. Distributors apply some customizations, improvements, tweaks and integration work which an upstream maintainer would reject to include by default. With regard to spec files, some upstream maintainers would also insist on modifying contributed spec files in a way they find "smart" or elegant, but which would obfuscate the packaging (e.g. generated %files lists, overuse of macros, heavy inline creation of extra files within spec files, ...).
I think of it this way: as a developer, I cannot possibly package well for all distros, but I may be able to package well for the one or ones I use heavily. Nonetheless, as a developer, I have to maintain the code in single units that is readily packaged by many distros, not just the one I happen to use.
Then -- as a developer -- make your software be trivial to package.
I agree fully with this.
And what I was trying to say is that feedback from the packagers should help the developers do that. If the process of generating a package is hard, then I want to know how to make it easier, so that the spec can be trivial.
That would not solve the problem of the "packager freak" who loves to turn his spec file into a little uncommented program and who does enough lobbying to get his spec file included as the upstream default.
As a developer, I want to make packaging as easy as possible across the board. Which means I need to be able to support not only Fedora, even that that is my distro of choice.
But that means that you may need to spend additional time on tweaking your "configure" scripts and aclocal code to deal with possible detection of differences between distributions. Something developers with a "works for me" mentality would rather avoid, in particular if they don't like other distributions. It ends with them accepting contributed patches reluctantly, if at all.