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

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

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


PS: we already have a bunch of packages with = depends on -all
packages, like qt.

Reply to: