[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