[Fedora-packaging] Compat packages: Any best practices, rules, guidelines?

Toshio Kuratomi a.badger at gmail.com
Fri Aug 28 05:13:10 UTC 2009

On 08/27/2009 03:23 PM, Ryan Lynch wrote:

> But I have a lot of questions, too, and I was hoping that anybody in the
> know could help me.
>  * Is anything about the compat convention standardized, or a matter of
> policy?  I saw that the FESCO discussed about the issue, a while back, but I
> feel like I may have missed something more recent.
I don't believe so but if someone cares they can submit a draft.  We
could certainly stand to standardize the use of compat-libfoo-1.0.2 vs
libfoo1-1.0.2 for instance.

>  * I can understand why large numbers of compat packages are frowned upon,
> and 15+ compats to support one measly application seems excessive, even to
> me.  Is this the kind of thing that would torpedo a package review,
> completely?  Or is there room for discussion, given a commitment to improve
> the situation (i.e., update the application) in time?
I would torpedo it.  But we don't have specific guidelines that cover
this.  So at the moment it's a matter of expressing the relative merits:

On the plus side: Another package that someone wants would be added to

On the debit side: Fedora is not a dumping ground for unmaintained or
poorly designed software (From "Non-objectives" on:

Often times, compat-libraries are no longer maintained upstream.  This
places more burden on the packager to fix bugs and security issues
without the aid of upstream.

Fedora is about moving forward.  Porting code forward to new libraries
is certainly in line with this goal.  writing patches to old library
versions is not so much.

>  * What kinds of compat packages, and what specifically about them, are
> considered bad?  I've noticed that some compats don't appear to be included
> in Fedora, like 'compat-python24'.  It seems like a useful package, but I'm
> seeing it in RPM Fusion--why didn't it pass review?
There's actually two kinds of compat packages.  We don't follow one
naming convention 100% for them but it's convenient to pretend we do:

* compat-foo is not for packages in Fedora.  It is the shared libraries
that are necessary for thirdparty packages to run with the old versions
of the libraries.
* fooX-X.Y.Z is a version of the foo library at SONAME version X.  This
includes headers and anything else needed to compile packages against
the library.

compat-python24 is actually an example of the latter despite the name.
There's several reasons its not in Fedora:

* The python maintainer was against it
* It's no longer maintained upstream
* Having the interpreter and stdlib is only a small part of the python
ecosystem.  We'd really want to have python modules as well.  unless we
did something like Debian has, we'd need to have separate packages for
each version -- so python-setuptools and python24-setuptools,
python-psycopg and python24-psycopg, etc.

Some people argue that all compat-foo packages are bad -- they're made
for code that can't be ported (or in some cases, merely recompiled)
against newer versions of libraries.  This usually means proprietary
applications.  However, locally created programs that are just not
distributed without thought to proprietary vs open source also fall into
this at times.

fooX-X.Y.Z is harder to justify a ban on.  There are drawbacks like
maintaining two stacks of a thing, puzzling out whether bug reports
really need to target the old version or the new version, whether
upstream supports both versions, how much work it is to make the two
versions parallel installable, etc.  But at times having the parallel
installable versions is a saving grace until upstreams and other distros
mobilise to help with the job of porting from one version of a library
to the next.

>  * In the future, what direction is Fedora taking the compat convention?
> What kinds of long-term issues should I worry about, if I want to get ahead
> of the curve?
To my knowledge, the general direction is to get rid of as many old
libraries as possible.  Instead, we work with upstreams to port code to
newer versions of libraries.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/packaging/attachments/20090827/ad888da3/attachment.bin 

More information about the packaging mailing list