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
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
