[Fedora-packaging] Compat packages

Ralf Corsepius rc040203 at freenet.de
Tue Mar 24 14:40:47 UTC 2009


Denis wrote:
> On 03/23/2009 04:37 PM, Ralf Corsepius wrote:
>>> 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).
> 
> To be honest, I fail to see the difference between both your cases 
> above.
The difference is substantial.

The key points are
* Choosing "unique package name"
A compat prefix can only be applied once, it's insufficient to handle 
several versions.

* Choosing the "nominal package" name.
Using a "compat-* package-prefix" forces all packages's specs which 
can't be upgraded to the latest version of a package to be modified.
Using a "versioned package name" ties a package's spec to a particular 
version.

> Compat packages are also meant to be parallel installable  (e.g.
> compat-gcc34),

Well, compat-gcc<N> is a twit of both approaches :)

> and "package<N>" also supply backward compatible 
> run-times
Correct. The "package<N>" approach is more flexible than the "compat-" 
convention.

Finally: compat-* is the tradtional approach RH has been using/RH seems 
to have favored, until ... packages were facing it's limitations ;)

Ralf




More information about the Fedora-packaging mailing list