Re: ITP: namazu2
At Fri, 18 Feb 2000 22:11:56 +0900,
Ryuichi Arafune <firstname.lastname@example.org> wrote:
> Do you mean "Debian MUST separate packages for different version."?
> For my case, I upgraded imagemagick (Major version 4 -> 5).
> At that time, I renamed the name of library package, libmagick4g to
> libmagick5 (*1). If what you say is our duty, I must maintain the
> libmagick4g. Because libmagick is not used only imagemagick
> (php-magick used libmagick4g.)
> However, I have thought that the maintainer of php-magick should build
> php-magick by libmagick5-dev(See Bug#57012) in that case.
Changes of major version mostly mean interface changes i.e. no compatibility.
If php-magick can be built by recompiling libmagick5 simply, it is a specific
case. For example, I uploaded new ALSA 0.5 library recently, but most of
packages can't work on it. Specifically, it takes a year and over that
alsamixer (included in alsa-utils) is ported to the new interface.
xamixer is removed because of non-porting. timidity will be also removed.
Most of ALSA plugins are also the same situations. That's why I separate
alsa-lib into two packages (and not to upload them into potato).
> Is it my misunderstanding? Do you mean that I must manage the old
There is the following sentence in policy-manual 4.3:
Packages which use the shared library should have a dependency on the
name of the shared library package, `<libraryname><soname>'. When the
<soname> changes you can have both versions of the library installed
while moving from the old library to the new.
This shows an advantage of splitting each shared library into several packages.
In also php-magick case, php-magick has the unmet dependency until it is
recompiled. It would be easy for a maintainer to upgrade a shared library
package simply (maybe just to use uupdate, or uscan?). However, as a result,
most of packages that depend on that library have unmet dependencies.
> Please let me know your thinking.
You don't have such a duty to maintain an old library. If you don't want to
maintain the old library, then you can make it orphan. This would cause
someone to take it over if he or she wants. At least, I think we should
prepare to coexist with several shared library packages for the future