[Fedora-packaging] Compat packages

[Ralf Corsepius]

Denis Leroy wrote:
> Tom "spot" Callaway wrote:
>> On 03/19/2009 08:44 AM, Richard W.M. Jones wrote:
>>> Is there any policy at all on compat packages?  I can't find anything
>>> except this oblique reference to "openssl" vs "openssl096b":
>>>
>>> https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Multiple_packages_with_the_same_base_name 
>>>
>>>
>>> There are a number of compat-* packages in Fedora.
>>>
>>> We would like to add one for celt (an audio codec), since the
>>> bitstream changes incompatibly in each release, and interoperability
>>> depends on an application always using the same specific version.
>>>
>>> (This is in relation to this bug:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=485245
>>> and the celt package in both Rawhide and RHEL 5)
>>
>> There is no formalized policy at this time. The last attempt by FESCo
>> was tabled, but is here:
>>
>> https://fedoraproject.org/wiki/BrianPepple/DraftCompatPackages
>>
>> My opinion is that compat- packages are acceptable in cases where the
>> primary (non-compat) maintainer agrees that there is value in the compat
>> packages, and that it does not encourage upstreams to remain on old APIs
>> unnecessarily.
> 
> My opinion also. On that topic, should we do something about compat 
> packages not explicitly named as such. For example, we ship 
> gtksourceview and gtksourceview2. Shouldn't they be called 
> 'compat-gtksourceview' and 'gtksourceview' respectively ?

No. These are 2 different historic ways to having been applied to 
introduce "compat packages".

1) Add "compat-*" packages

2) Use versioned package names "package<N>"

Both approaches have pros and cons each.

E.g.
* compat-* package typically supply "backward compatible run-times". 
They very often aim at "keeping users' applications" happy.

* "package<N>" package often aim at "parallel installation", often 
stemming from times when some underlying package has undergone major 
API/ABI changes, while it's clients/users have not been updated to the 
new version yet (classic example: gtk (gtk1) vs. gtk2).

> Where do we draw the line ?
Why do you want to draw a line? There are many aspects why one solution 
might be preferable/better suitable in one or the other situation.

Ralf