Issues with releasing bzip2 1.0.1
Hi have some issues with releasing bzip2 1.0.1.
Namely, the current bzip2 source package (0.95d-3) generates three
packages:
libbz2
libbz2-dev (depends on libbz2)
bzip2 (depends on libbz2)
Quite a few packages depend on libbz2 0.95b.
And 0.95d-3 has been released only a couple of days ago.
For some reasons, libbz2-1.0.1 has to conflict with libbz2 << 0.95b-3.
Solution #1:
I release the bzip2 1.0.1 source as bzip2, generating the packages:
libbz2-1.0
libbz2-dev
bzip2
Archive situation: the bzip2 source overwrites the 0.95d-3
source. The libbz2-dev and bzip2 binaries overwrites the 0.95d-3
binaries. We're left with both libbz2 and libbz2-1.0 binary packages
(for old packages compatibility).
Problem: Nobody can rebuild libbz2 from source since it's not there
anymore. Especially some archs that haven't caught up with
0.95d-3. And we end up with a lot of uninstallable packages since
- all the packages depending on libbz2 depend on 0.95b-x.
- the new libbz2-1.0 conflicts requires that libbz2 is at
least 0.95b-3.
- 0.95b-3 is not available (at least on some archs).
Solution #2:
I release the bzip 1.0.1 source as bzip2-1.0, generating the
packages:
libbz2-1.0
libbz2-dev
bzip2
Archive situation: we end up with two bzip2 source packages. The
libbz2-dev and bzip2 binaries overwrites the 0.95d-3 binaries. We're
left with both libbz2 and libbz2-1.0 binary packages (for old
packages compatibility).
Problem: we have two source packages generating bzip2 and
libbz2-dev.
Solution #3:
Same as #2, except that I also release bzip2 0.95d-4 which only
builds the libbz2 package. It would allow non-i386 archs to catch up.
Anybody has dealt with the same issue with packages generating both
libraries and binaries? Which is the way to go? I would tend for #3
myself.
Phil.
Reply to: