Bug 142433

Yup, been on my todo list, thanks for the reminder.

FWIW. all packages that have paths like /usr/lib/python2.4
are going to need rebuild so that
    a) brp-python-bytecompile insures that all *.pyc and *.pyo
    are automagically generated and included in the package.
    b) All packages are marked with
        Requires: python(abi) = 2.4

And yes, it will be a while before other, perhaps redundant,
package dependency markers like
    Requires: python >= 2.4
and
    Requires: python-abi = 2.4
are manually flushed from spec files in preference to
the automagically generated, and rpm name-space wrapped,
    Requires: python(abi) = 2.4
Note that the redundancy hurts nothing, it's just redundant
expressions of the same goal, i.e. to associate the correct
version of python with packages, like beecrypt-python, that
contain python modules insalled onto /usr/lib/pythom2.4
paths.

Jeff,
current CVS contains beecrypt-4.0.0, which seems to break
binary compatibility with beecrypt-3.1.0 (compare rsa.h)
without bumping the soname.

So, I can:
a) drop the CVS update and create a new 3.1.0 package
b) check that nothing in the distro uses the rsa functions
   (and if it does, fix that) and update to 4.0.0, hoping
   that nobody else uses the functions
c) bump the soname in an upstream-incompatible way and update
   to 4.0.0

Either way, this is a nontrivial change and you own the package,
so I'd appreaciate your opinion.
Thanks.

beecrypt-4.0.0 changes soname IIRC (per my memory of conversation
about the rsa changes ~9/2004 with beecrypt maintainer), that is
no ABI breakage. Or perhaps I'm wrong, I have not looked,
because the ultimate question is whether ABI changes are permitted
in FCn or not.

ABI compatibility a mandatory requirement for FCn last I heard.
But ABI changes are always dealt with case-by-case.

Reverting to 3.1.0 is always possible, so is porting, the changes
are neither large nor important. In fact, the changes are miniscule
enough that versioned symbols could solve.

Changing soname without coordinating upstream is silly,
particularly when Bob Deblier, the beecrypt maintainer,
has been incredibly helpful.

I seriously doubt whether the rsa ABI chnage really matters,
beecrypt is there for rpmlib, not anything else, afaik, but
    rpm -q --whatrequires ...
used intelligently will tell all.

Without criteria for a decision, like whether beecrypt ABI changes are
permitted in FCn, I cannot make the call. Given a call, the rest is
just gear turning, whether you or I do matters little.

If it was up to me, I'd go with latest provably stable beecrypt into
FCn in a flash, the rsa changes are not serious, and I do not believe
anything other than rpmlib uses beecrypt.

I woould also think about dropping beecrypt-python, rather than
fixing, since minimal package count in FCn seems to be the current
focus.

NEEDINFO:
     Is a beecrypt ABI change permitted in FCn? Yes or no, please.

Jeff,
beecrypt-4.0 doesn't change soname, it stays at beecrypt.so.6

I'm definitely the wrong person to ask whether ABI changes are permitted
in FC, but I have decided anyway :)

rpmlib actually uses rsavrfy (), one of the incompatibly changed functions,
so breaking binary compatibility would silently break rpm's PGP verification
(until rpm rebuild); that sounds like a good enough reason not do do it.

I have rebuilt beecrypt-3.1.0-7, fixing at least the python-2.3 dependency.

Robert and Jeff, thanks.