Re: binary NMUs and version numbers
Steve Langasek <vorlon@debian.org> writes:
> On Fri, Nov 26, 2004 at 12:41:04PM +0100, Goswin von Brederlow wrote:
>> Scott James Remnant <scott@netsplit.com> writes:
>
>> 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.
This should then best be included in the packaging manual or best
packaging practices and in the (to be written) multiarch transition
guidelines. I will save this mail and hope I remeber it when the time
comes to write the guidelines.
>> 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.
MfG
Goswin
Reply to: