Brian May wrote:
> Richard Braakman wrote:
> >I've read Brian's summary, but I still don't see the point of this
> >operator. It seems that what you want to accomplish can be
> >done just as easily with:
> >
> >Depends: hwarch-${Arch}, ${shlibs:Depends}
>
> You can't say
>
> Depends: hwarch-i386 ^ hwarch-sparc
As long as you're making the basic assumption that the package
that is built becomes dependent on the `dpkg --print-architecture`
of the build environment, you may as well use the Architecture:
header that we already have. Thus:
Architecture: sparc i386
Depends: hwarch-${Arch}, ${shlibs:Depends}
If this is too limited (and it may be), then so is the
hwarch-i386 ^ hwarch-sparc approach. A ${hwarch} substitution
is probably necessary in such cases, together with some sort
of dpkg-hwarch tool.
Note that we already have the problem that some source packages build
different sets of binary packages on different architectures. There's
no real support for that; we just wing it. This causes the archive
check scripts to whine at me a lot :-)
> Afterthoughts (assume same hwarch):
> - is there any reason that ${shlibs:Depends} might change in any
> way for another OS, but the package shouldn't be recompiled?
In a way, yes... the alpha tree already has this, since it calls
its libc "libc6.1". This means that every Debian kernel must
call its libc "libc6.1" on the alpha, to be compatible.
We can fix this more easily with versioned Provides, though.
> - is there any reason the ${shlibs:Depends} migh remain constant
> for another OS, but the package should be recompiled?
Yes, but I think such cases are bugs. The ${shlibs:Depends} remains
constant iff the library sonames are the same. They shouldn't be the
same if the binary interface differs, but they might be. We've seen
this even with libraries on a single system.
Richard Braakman
