Adam Borowski <kilob...@angband.pl> writes: > 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. Yes, I agree. >> 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? 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. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
