spec.in

[Havoc Pennington]

John (J5) Palmieri wrote:
> I still don't understand what the differences between distros is right
> now.  I haven't looked at anyone's spec files besides my own but from
> evidence across upstream projects which don't particularly care about
> distros and will happily run on any one, it all just works. 

You can write a spec file that's moderately portable if you avoid 
detailed dependencies and things like that, just using RPM as a 
glorified tar/zip. Not likely to get a spec file like that accepted in 
Fedora though.

Fedora specifics would include dependencies with epoch or RPM release 
involved, sounds like these selinux audit patches are Fedora specific, 
-debuginfo is Fedora specific, there are lots of little things.

There's nothing wrong with this. The whole design of RPM is to be the 
way you assemble a bunch of upstream packages into an integrated 
distribution. i.e. the idea of a spec file is to describe how to convert 
the upstream tarball into a distribution-specific binary build.

If the spec file contains nothing distribution-specific, the spec file 
should also be incredibly short.

A lot of people confuse RPM with a format for third-party installers, 
like a Windows .msi. IMHO it sucks in that role, though it can be forced 
into it if you try hard enough (and keep your RPM usage dumb and 
tar/zip-like).

Also just purely as a logistical issue, when maintaining a package in 
Fedora or RHEL you want to be able to have the spec file in the 
distribution CVS, and be able to branch it when the whole distribution 
branches and apply security backports without upgrading to upstream.
I imagine the same is true for Novell or Ubuntu.

It isn't really practical to maintain the spec file upstream until you 
need it different and then move it, then move it back, then move it 
again, etc. Instead distributions keep a pretty empty spec file if they 
have no changes, and they can insert changes as required.

I know I'm probably telling you what you know, but for the benefit of 
people who haven't been distribution package maintainers I thought I'd 
write it out ;-)

> In any case the way to fix it is not to have a universal spec file which
> will just go unmaintained (I have seen this happen in a lot of
> projects).  The fix is to identify what in particular is causing real
> differences in the distros and resolve this by coming to a consensus and
> setting agreeable standards.

Exactly, we should strive to have no patches in distribution RPMs, 
unless those patches really are distribution-specific for whatever reason.

I still haven't heard a concrete example of dbus differing among 
distributions from an application perspective, though (other than 
version skew, which is just unavoidable until 1.0 arrives).

Havoc