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 Fedora.

On the debit side: Fedora is not a dumping ground for unmaintained or poorly designed software (From "Non-objectives" on: http://fedoraproject.org/wiki/Objectives)

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.

-Toshio