XPost: linux.debian.ports.powerpc 
 From: bunk@debian.org 
  
 On Sun, Sep 07, 2025 at 04:11:10AM +0200, Guillem Jover wrote: 
 > 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. 
  
 This sounds like a lot of potential pain for near-zero benefits. 
  
 Like we might end up with an oldstable upload to security-master that 
 gets built and a DSA published, but then ftp-master refuses to import 
 the packages from the DSA for the next point release. 
  
 powerpcspe, kfreebsd-amd64, kfreebsd-i386 and ia64 were until recently 
 actively maintained in ports. 
  
 This implies that the arch definitions are used in a gazillion places. 
  
 Even kopensolaris is used in the Architecture list of a package in 
 trixie that does have plenty of CVEs (grub2). 
  
 >... 
 >   * 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, 
 >... 
  
 I agree with you that obsolete architectures should eventually get 
 removed, but I do not see the urgency to do it in this order. 
  
 IMHO best would be a deprecation process where lintian emits an error 
 for architectures that should not be used in forky, and the actual 
 removal happens when trixie gets removed from ftp-master. 
  
 The lintian tag could also be used to file RC bugs on the remaining 
 packages in a year. 
  
 > Thanks, 
 > Guillem 
  
 cu 
 Adrian 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2)