Re: [multiarch] Proposal for *-dev packages
Daniel Kobras <kobras@debian.org> writes:
> On Wed, Jan 14, 2004 at 11:38:59PM +0100, Goswin von Brederlow wrote:
> > Rename libfoo-dev to libfoo-arch-dev and have lib-foo-dev depend on
> > the right set of specific debs. Is that better?
>
> Yes, but wasn't your aim to make libfoo-arch1-dev and libfoo-arch2-dev
> installable in parallel?
>
> > If the information comes from configure get it from configure. Don't
> > stick it into the headers at compile time, thats just stupid.
>
> I don't see why it would make sense to re-run configure on a user's
> system when the information is already present at compile/configure
> time. And I don't see the stupidity in
>
> foo.h:
> /* Want to be portable to systems w/o int64_t */
> typedef long foo_int64;
Thats just plain wrong on 32bit systems. You need an #ifdef construct
there already, you have to check the size of long at some point.
But keeping it your way, the right[TM] way for such compatibility
would be to test for stdint.h in the configure script and then
#ifndef HAVE_STDINT
typedef long int64_t
#endif
> foo.pc:
> Libs: -L${libdir} -lpthread
>
> You're trying to shoehorn data into binary-all that is inherently
> architecture dependent.
foo.pc files aparently are in /usr/lib/, that means they go to
/usr/lib64/ for 64bit multiarch. But even though there is no
architecture dependend information in your example. That foo.pc file
could be copied or linked to both places in the -dev arch: all
package.
If it realy is architecture dependend move it into the -helper,
-static, -whatever package you choose to use for the architecture
dependend stuff. And yes that means you have to create that one new
package you have to create anyway for multiarch.
MfG
Goswin
Reply to: