Re: possible mass-filing of bugs: many shared library packages contain binaries in usr/bin
On Mon, May 06, 2002 at 06:05:09PM +0900, Junichi Uekawa wrote:
> On 05 May 2002 21:09:49 -0700
> Stephen Zander <gibreel@debian.org> wrote:
> > There are two possible scenarios here:
> >
> > a) The package is upgraded in such a way that library replacement
> > occurs. In that case, binary replacement occurs at the same time and
> > there is *no differecnce* to the user.
>
> Wrong.
>
> A user may have external binary (outside of Debian control) that links to
> the library. That binary will stop starting.
No, that binary will be fine, as will all others which link with the
library. It has just been replaced, but its soname is the same. This has
nothing to do with whether the binary happens to have been installed by a
package.
> > b) The package is upgraded by giving the package source a new name
> > (e.g. libdb[234] or the infamous libgal* packages). In this case the
> > maintainer needs to be sufficiently clueful to avoid the inevitable
> > conflict that will occur & prevent both packages from being installed
> > at the same time unless the --force-overwrite flag is in effect (see
> > the relevant flamewar elsewhere for why this is or isn't a good idea),
> > dorwning them in RC bugs & at least keeping the package out of
> > testing. Having binaries in -dev packages does not avoid this
> > situation unless there is one & only one -dev package in the archive.
>
> No, -dev should have the following entry:
>
> Package: libsomething1-dev
> Provides: libsomething-dev
> Conflicts: libsomething-dev
>
> so that only one version of the -dev package will be installable.
That is exactly what Stephen said.
> > Either way it is not *automatically* a bug to have a binary in a library
> > package.
>
> I have clued you to the problems and solutions, can you still say that
> again?
I agree that it is not, in general, a good idea to provide programs in a
shared library package. However, it is not a bug in itself, as there are
reasonable and useful ways in which it can be done safely. For example, if
I supply a libfoo1-whizbang script in my libfoo1 package which would coexist
with a libfoo2-whizbang script supplied by a future libfoo2 package.
--
- mdz
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: