Bug 142433 - beecrypt-python depends on python 2.3
beecrypt-python depends on python 2.3
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: beecrypt (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Miloslav Trmač
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-09 13:17 EST by Robert Scheck
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version: 3.1.0-7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-04 10:52:22 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Robert Scheck 2004-12-09 13:17:31 EST
Description of problem:
beecrypt-python depends on python 2.3, because it is built against 
python 2.3.

Version-Release number of selected component (if applicable):
beecrypt-python-3.1.0-6

Actual results / Expected results:
I think,
  "Requires: python >= %{with_python_version}" 
in the beecrypt spec file should be changed to
  "Requires: python(abi) = %{with_python_version}"
to avoid such things in the future.

And the important: beecrypt should be rebuilt against python 2.4...
Comment 1 Jeff Johnson 2004-12-09 20:22:37 EST
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.
Comment 2 Miloslav Trmač 2005-01-30 15:07:07 EST
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.
Comment 3 Jeff Johnson 2005-02-01 13:32:17 EST
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.
Comment 4 Miloslav Trmač 2005-02-04 10:52:22 EST
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.

Note You need to log in before you can comment on or make changes to this bug.