Re: possible mass-filing of bugs: many shared library packages contain binaries in usr/bin
Jeroen Dekkers <jeroen@dekkers.cx> immo vero scripsit:
> > This binary should be in -dev so that when linking binaries,
> > applications can use the information.
> >
> > Not required at all for running applications linked with it.
>
> I wouldn't care about moving all these thing to compile-time, but some
> people want to support non-free software which can't be
> recompiled. Then a program needs to find out which version of libpspell
> it's talking to and which directories you use.
>
> I think it should be done at run-time anyhow, it gives you more
> flexibility.
ld.so wants to find that information from the ELF data.
But I am not that expert in pspell, it might be used in many
different ways I do not know.
I'm trying to weed out potential bugs,
and I have been fixing such bugs for the last few months.
I know they are only potential bugs, but I am pretty
annoyed that they are there, and cause much problems.
and what's so difficult about this paragraph (from policy) ?
If your package has some run-time support programs which use the
shared library you must not put them in the shared library package.
If you do that then you won't be able to install several versions of
the shared library without getting filename clashes. Instead, either
create a third package for the runtime binaries (this package might
typically be named `<libraryname>-runtime'; note the absence of the
<soversion> in the package name), or if the development package is
small you may include them in there.
regards,
junichi
--
dancer@debian.org : Junichi Uekawa http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4
Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: