Re: Formal definitions of Provides and Replaces
Andrius Merkys <andrius.merkys@gmail.com> writes:
> thanks for pointing this out. I was quite surprised that
> Provides/Replaces does not formally require the providing/replacing
> binaries to completely cover provided/replaced binaries.
> The reason I'm asking is the removal of binaries of blacs-mpi, which is
> indicated as provided/replaced by scalapack now. However, scalapack's
> libraries have other sonames, what requires adaptation and rebuilding of
> all packages depending on blacs-mpi. I have spent quite some time to
> figure this out when packaging espresso. Isn't this a bug in scalapack?
I think you're expecting a stronger guarantee than Debian necessarily
provides here. Even a newer version of the same package doesn't have to
provide all the same files as an earlier version of the package.
Some history is here: https://bugs.debian.org/886711. It sounds from that
bug at least like the functionality provided in blacs-mpi is now provided
by scalapack, and at least some packages could just be rebuilt against
scalapack to handle that transition. That's about all that's needed to
justify a Provides/Replaces. There isn't a requirement that everything
work; it's a transition, and the functionality provided is changing (in
this case, apparently based on upstream changes). Using Provides/Replaces
is a mostly pragmatic decision: does it create less work than just
removing the package completely and forcing sourceful uploads of all other
packages? (With an eye to what the upgrade experience for Debian users is
as well, of course.)
As part of that transition, it looks like exactly what you said
("adaptation and rebuilding of all packages depending on blacs-mpi") was
done for the packages in Debian.
Usually it's not worth the effort to diverge too far from upstream in
trying to maintain backward compatibility. If upstream has decided not to
maintain that compatibility, trying to do it ourselves in Debian is rarely
a good use of scarce resources. That sometimes means package-breaking
transitions that require a bit of work for dependencies.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: