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

Re: Enhanced syntax for Architecture field (Was: Usage of real m68k hardware)



On Wed, Mar 28, 2018 at 08:28:23PM +0200, Andreas Tille wrote:
> On Wed, Mar 28, 2018 at 09:24:12PM +0300, Adrian Bunk wrote:
> > 
> > Dependency fields have negative syntax like !m68k, for the Architecture: 
> > field this is only possible with a complete list of all architectures
> > except the one you want to exclude.
> 
> I agree this could really simplify things and I would have used this
> syntax in several cases.

Note that pretty much every place we have a list of architectures expects a
different syntax.  This causes confusion, and, as you say, is painful due to
a lack of such functionality.

I don't remember the details, but IIRC dependencies also have a limit of not
allowing both positive and negative specifiers.

Thus, if we'd change this, what about changing the rules to:
an architecture is allowed iff:
it matches at least one positive specifier -or- there's none,
and it doesn't match any negative specifier.
(Ie, negatives have priority, no positives assumes "any".)

The other change I'd make would be adding extra wildcards:
* {big,little}-endian
* {32,64,128¹}-bit
* "fast" (and/or it's near-complement "slow")

Thus, Andreas would mark his package, avoiding wasting time of either his or
small-arch porters.


Meow!

[1]. riscv128 already exists, although not in dpkg's arch table.  And at
least Google has enough storage in its servers to require more than 64-bits
to address if you use it as virtual memory.  And, recent extension to la57
was just 12 years after la48, which gives an estimate for when 64 bits won't
be enough for anyone even for a single machine.
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄⠀⠀⠀⠀ A master species delegates.


Reply to: