Re: binary NMUs and version numbers
Scott James Remnant <scott@netsplit.com> writes:
> On Fri, 2004-11-26 at 10:28 +0100, Goswin von Brederlow wrote:
>
>> Andreas Barth <aba@not.so.argh.org> writes:
>>
>> > * Scott James Remnant (scott@netsplit.com) [041126 07:10]:
>> >> Maybe we should look at why this is needed? binary-all packages
>> >> depending on a binary-any package from the same source with
>> >> Depends: (= ${Source-Version})
>> >>
>> >> Is there any way we can eliminate the need to do *that*?
>>
>> We can't eliminate the need for this. -dev packages have to depend on
>> the exact version of their lib package. With multiarch coming up this
>> will be far more commonly needed than now.
>>
> Surely binary-all -dev packages are pretty rare, I would have thought
> most would be binary-any due to that little ".a" file in them.
>
> Scott
> --
> Have you ever, ever felt like this?
> Had strange things happen? Are you going round the twist?
multiarch will usualy have:
libfoo (any, libs for 32 or 64 bit)
libfoo-common (all, shared files for both 32 and 64 bit)
libfoo-dev (any, .a files for 32 or 64 bit)
libfoo-common-dev (all, mainly include files)
There might not be a libfoo-common needed but libfoo-common-dev for
the include files would be very widespread I guess. Most libs don't
have arch specific include files and a /usr/include/i386-linux/foo/
and /usr/include/amd64-linux/foo/ containing identical files would be
stupid.
[same for i386(qemu)+ppc, mips o32+n32+n64, s390+s390x, ...]
I know all those new extra package suck but suggest something better
to suport multiarch systems.
MfG
Goswin
PS: we already have a bunch of packages with = depends on -all
packages, like qt.
Reply to: