Naming of a .pc file: package.pc vs package-version.pc

[Tollef Fog Heen]

]] Dan Nicholson 

| I think you would only want to add the version to the name if you
| needed to distinguish it from a separate version of the same package
| that may also be installed. A lot of GNOME packages did this when they
| went to 2.0 to allow the 1.x versions to be parallel installable.
| However, to truly be parallel installable, there are lots of other
| criteria to consider, too. Most of this thinking flows from something
| Havoc Pennington wrote a few years back:

Havoc talks about co-buildability, so being able to install multiple
versions of the development package (libfoo-dev in Debian, foo-devel in
RH and friends) at the same time, and be able to build for both versions
at the same time.

I don't think this should be a goal.  Havoc points out that you can
break backwards compatibility if you version the headers and the .so
link, which is true.  This doesn't mean the cost of breaking backwards
compatibility goes down: older apps and libraries still have to be
ported to the new API, and you end up with a possibly longer transition
period.  In addition, if you only break a little bit of your API, you
still require all older apps and libraries to change their required
version to use the newer library, even if the API they use is not
changed at all.  So to say, the latter approach is selfish: you get less
work (you can break backwards compatibility), but you impose more work
on everybody else when you up the version number.

Not having co-installability means you might need to uninstall and
install packages when you build different pieces of software.  I don't
really consider that a problem.  Use pbuilder, mockbuild (I think it's
called) or something else suitable for your platform.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are