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

Re: Debian GNU [was: smarter way to differ architectures needed?]



Richard Braakman wrote:
>Gordon Matzigkeit wrote:
>> [Brian, your summary of the idea is nearly perfect.  Thanks for taking
>> the time to explain this in a clear way that I wasn't able to.  I
>> really depend on people such as you to interpret my grunts and
>> hand-waving and come up with a coherent explanation that makes sense
>> to other people. ;)]
>> 
>> To reduce confusion: the new symbol we're talking about is really just
>> `XOR' (exclusive OR), and the old symbol is `OR' (plain old inclusive
>> OR).  In keeping with dpkg's convention of using the C bitwise
>> operators, let's make the new operator `^' instead of `||'.
>
>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

(ie it is not compatable with anything else). In the future, this could
be important for programs that may require assembler language (eg for
speed) but haven't yet been ported to every architecture. I agree that
this a probably a weak argument, as I can already think of other ways to
do the same thing.

You may be right though about the glibc dependancy, it probably be
better to use the existing mechanism for that.

Right now, I can't see any real reason why using "^" is worth
the extra complexity (Gordon?), but will continue thinking
about the issue.

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?
- is there any reason the ${shlibs:Depends} migh remain constant
for another OS, but the package should be recompiled?

>And this is with less hardcoding to boot; there's no need for
>dpkg to know what to do with "hwarch-sparc ^ hwarch-i386".
>The standard variable substitution facility is quite powerful.

With what I was saying, dpkg will never see the "^" tokens
in much the same way dpkg never sees the "${...}" tokens.

Brian May <bam@snoopy.apana.org.au>


Reply to: