XPost: linux.debian.ports.powerpc 
 From: glaubitz@physik.fu-berlin.de 
  
 Hi Guillem, 
  
 On Sun, 2025-09-07 at 04:11 +0200, Guillem Jover wrote: 
 > 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. 
  
 Does removing architectures from dpkg really make such a difference that 
 it's necessary to do that so early after the architecture was dropped? 
  
 I personally think that we shouldn't drop architectures at all as to not 
 hamper projects like rebootstrap [1] which allow bootstrapping Debian from 
 source on any given architecture. 
  
 And if someone wants to bootstrap Debian for powerpcspe or ia64, for 
 example, 
 why should we actively block that? 
  
 Adrian 
  
 > [1] https://wiki.debian.org/HelmutGrohne/rebootstrap 
  
 -- 
  .''`.  John Paul Adrian Glaubitz 
 : :' :  Debian Developer 
 `. `'   Physicist 
   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2)