On Sat, Sep 09, 2023 at 02:53:00PM -0700, Russ Allbery wrote:
> Samuel Thibault <sthiba...@debian.org> writes:
> > Architecture: !s390 !s390x
> > Architecture: !hppa !hurd-any !kfreebsd-any
> > 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.

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

> 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.

Agreed, but it might be good to say "it would be good to have this",
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.


> 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.

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


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Elemental clouds:
⣾⠁⢠⠒⠀⣿⡁ • earth: cumulogranite (aviation)
⢿⡄⠘⠷⠚⠋⠀ • fire:  pyrocumulus (forestry, volcanism)
⠈⠳⣄⠀⠀⠀⠀ No known relations of clouds to air or water.

Reply via email to