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