[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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:
> > >>>>> "Junichi" == Junichi Uekawa <dancer@netfort.gr.jp> writes:
> >     Junichi> They don't upgrade properly.
> > 
> > "You keep using that word.  I do not think it means what you think it
> > means."
> I will explain it to you a bit more in the hope that you can understand.
I still don't understand why they don't upgrade properly.

> > 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.

I'm interested to hear your solutions for this. Dpkg doesn't know
about external binaries, so how do you want to make it take those
binaries in account? 
> > 
> > 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.

I took a random example from the list (there are probably more of
these examples, or I was just lucky to get this one). The lucky
package was libpspell4. The binary in that package is

Now what is this binary doing? It gives the following 3 pieces of
information: version (.12.2), datadir (/usr/share), pkgdatadir
(/usr/share/pspell). What  the hell should this package do in *-dev?
It's given information about the pspell installation it is coming with.

> > 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?

Could you please clue me too why the above described situation is
buggy and how it should be done better?

Jeroen Dekkers
Jabber supporter - http://www.jabber.org Jabber ID: jdekkers@jabber.org
Debian GNU supporter - http://www.debian.org http://www.gnu.org
IRC: jeroen@openprojects

Attachment: pgpCmuKj4qP7r.pgp
Description: PGP signature

Reply to: