XPost: linux.debian.ports.powerpc 
 From: guillem@debian.org 
  
 Hi! 
  
 On Thu, 2025-09-04 at 14:48:05 +0300, Adrian Bunk wrote: 
 > On Thu, Sep 04, 2025 at 03:25:57AM +0200, Guillem Jover wrote: 
 > > About whether there's any necessity to remove architectures, yeah, we 
 > > could leave them around, but that also has a cost in that it is 
 > > confusing to expose things that are currently not viable, and that 
 > > people might end up trying to support and end up placing in package 
 > > metadata for example, or tooling. 
 > 
 > Please correct me if I am wrong, but aren't there issues when dpkg on 
 > ftp-master does not know about an architecture in the Architecture field? 
  
 > Would dak on ftp-master running forky reject uploads of trixie packages 
 > like libreoffice or qemu? 
  
 Yes, dak seems to validate architecture names from the .dsc Package-List 
 field (which gets generated from the debian/control Architecture field, 
 so arch restrictions in dependencies do not seem relevant/problematic), 
 but my impression has been that it would indeed only reject new uploads. 
 This can still be problematic, but if such an upload is required, then 
 the obsolete arch references can be (in general) easily be removed from 
 debian/control at that point as well. 
  
 The way I see it: 
  
   * removing arches is something that does not happen very often; 
     up to now only three batches in two release cycles: 
     - 1.17.x: removed lpia in 2014-10 
     - 1.22.x: removed avr32, m32r, tilegx in 2023-08; 
               removed arm64ilp32, uclinux-any, knetbsd-any; and 
               restricted CPU wildcards for kfreebsd, kopensolaris, hurd, 
               freebsd, dragonflybsd, solaris, darwin and aix into 
               fewer arches in 2023-12. 
  
   * these batches should ideally and in general happen early in the 
     release cycle, which should give ample time to remove obsolete 
     references. 
  
   * only for architectures that are currently not in actual use 
     or have never existed (so nothing in say Debian oldoldstable, or 
     under LTS or ELTS, or similar). 
  
   * removing them from dpkg first, means any thing like lintian, 
     which uses or syncs its arch list from dpkg, will start emitting 
     warnings/errors, and people can start removing references w/o 
     need for a mass build filing; for example for the current batch, 
     from the candidates, I see: 
     - kfreebsd-* at least refs in 252 source packages, 
       with 119 in Package-List. 
     - kopensolaris-* at least refs in 3 source packages, 
       with 3 in Package-List. 
     - powerpcspe at least refs in 46 source packages, 
       with 26 in Package-List. 
  
 For the previous iterations in the 1.22.x cycle I did a bug filing 
 pass, but I see now I left some non problematic instances for 
 m32r (Build-Depends), hurd-alpha (Build-Depends) and 
 kfreebsd-alpha (Build-Depends). And a problematic one for 
 knetbsd-any (Architectue). I also see now there are also other 
 pre-existing instances for architectures that have never existed in 
 dpkg (such as avr, or any-x32). Will be filing reports for some of 
 those. 
  
 So once/if any of those candidates for the next batch get removed, 
 I'd wait a bit in the release cycle, then start going over the 
 remaining source packages and send patches to remove old refs. 
  
 Thanks, 
 Guillem 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2)