Hello,

I didn't find a previous discussion on this: it would be useful to
support negated architecture specifications in the debian/control
Architecture field, so that we can e.g. write:

Architecture: !s390 !s390x
(for xorg stuff)

Architecture: !hppa !hurd-any !kfreebsd-any
(for java stuff)

and even things like

Architecture: linux-any kfreebsd-any !hppa !m68k-any

which would be understood as [ (linux-any or kfreebsd-any) and not hppa
and not m68k-any ]. I.e. if no positive specification is set, an "any"
positive specification is assumed.

That would help to remove quite a few entries of
https://buildd.debian.org/quinn-diff/experimental/Packages-arch-specific
and avoid packages with some java bits to have to hardcode the list of
ports on which java jni bindings packages should be built.

I guess support would be needed in dpkg, lintian, etc.

Samuel

Samuel Thibault <sthibault@debian.org> writes:

Hi Samuel,

I agree that this would be useful.  This has come up frequently over the
years, and back when I was maintaining architecture-specific packages, the
lack of this feature was often annoying.

But (as may be obvious from the long delay in even getting a response),
Policy can't drive the implementation of this change and therefore
probably isn't a good place to start with the request.  I think it would
need to start with dpkg and ftp-master (for DAK).  I'm therefore probably
going to have to close this bug against Policy as unactionable since I
don't know of any efforts towards implementing this support, and Policy
would only be able to change once the support is available.

If I misunderstood the current state, please do let me know.

and send a bug/mail to the relevant teams, asking if there are objections
before anyone spends work to implement this.

I for one have currently no less than three related ideas:
 * this
 * richer arch aliases (better than current dpkg aliases; could be
   implemented like shell foo-$@-bar word multiplication, thus linux-64bit
   would expand to linux-amd64 linux-arm64 linux-s390x ...); idea was kind
   of shot before though
 * replacing explicit arch names in source packages by facets (like:
   x86, little-endian, sse2, time64, ...) that are expanded at build time;
   procrastiplanning to propose this

It's good to discuss such things -- if someone offers to implement such a
change.

Could we oh so please have this as a policy policy in other cases, too?


Meow!

Adam Borowski <kilobyte@angband.pl> writes:

Yes, I agree.

Yes, historically I've been reluctant to close Policy bugs that indicate
real problems even if no apparent forward progress is being made on that
bug, but I'm starting to think this is too conservative and keeping really
old stalled bugs open is often not useful.  However, there are a lot of
bugs and I don't touch them very frequently, since I'm trying to focus on
closing bugs that do have forward progress.

If you or anyone else has a list of bugs that you think fall into that
category (no known efforts towards an implementation, Policy can't change
until that implementation happens), please do send a list.  (Feel free to
send that privately if you think it might be controversial.)  I'm happy to
take a look.

Please remove the following email address:  e.little598@gmail.com