On Tue, 8 Jun 2010 14:47:57 +0200, Patrice wrote:
> Hello,
>
> I would like to package a more recent version of hdf5 (in a private repo,
> but the issue is clearly there for EPEL). According to the naming guideline,
> with hdf5-1.8.4, the name could be along hdf518. But this is a bit annoying.
For the "more recent version" of package to encode its version into its
%{name} is a flawed scheme. When the most recent version moves forward, you
would be stuck. With a package name that refers to an old version (and not
being clear about that, btw). Sort of hdf518 -> hdf519 -> hdf520 or
confusing naming like hdf518-1.8.4 -> hdf518-1.9.0. Only way out would be
to change the package %name again (which would create orphans unless you
also added "Obsoletes" - and hope you never run into competing "Obsoletes").
The most recent version should occupy the base name: hdf5 (or upper-case
HDF5). Then old versions can stick to an extended base name, which won't
change.
Since hdf5 already ends with a digit, appending further digits to that
name would be ugly. Why not be more verbose and create package names, such
as hdf5-REL16-1.6.10, hdf5-abi16-1.6.10, hdf5-branch16-1.6.10, or
hdf5-release16-1.6.10?
> Wouldn't it be better to have an exception and allow hdf5-18?
"Better" in which way?
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging
