On Fri, Nov 26, 2004 at 12:41:04PM +0100, Goswin von Brederlow wrote:
> 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.
Assuming all of the above, it seems you've still only made a case for
binary-arch packages depending on a binary-all package,
libfoo-common-dev (= ${Source-Version}). Proper handling of Source-Version
in recompile-only NMUs would ensure this works correctly; since no binary-all
packages should ever be part of a recompile-only NMU, Source-Version ==
Binary-Version for all binary-all packages.
If you have
libfoo-dev Depends: libfoo, libfoo-common-dev
libfoo Depends: libfoo-common
all of your strictly versioned dependencies are arch: any -> arch: all.
Since libfoo-common-dev isn't going to be usable on its own anyway (the .so
links are all arch-specific in a multiarch env and therefore go in
libfoo-dev), I don't see any reason for libfoo-common-dev to have a
duplicate dependency on libfoo.
As long as we avoid foo-all Depends: foo-any (= ${Source-Version}),
recompile NMUs *can* be handled cleanly with additional Source-Version
handling, AFAICT.
> PS: we already have a bunch of packages with = depends on -all
> packages, like qt.
Actually, those packages are now arch: any to work around the current
limitations; but again, any -> all deps seem to be much less problematic in
the long run than all -> any deps.
--
Steve Langasek
postmodern programmer
Attachment:
signature.asc
Description: Digital signature