XPost: linux.debian.ports.powerpc 
 From: guillem@debian.org 
  
 Hi! 
  
 On Sun, 2025-09-07 at 20:00:12 +0300, Adrian Bunk wrote: 
 > On Sun, Sep 07, 2025 at 04:11:10AM +0200, Guillem Jover wrote: 
 > > 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. 
  
 The benefit, is that this removes confusing entries that are of no 
 current use, and avoids people ending up trying to still support them. 
  
 > 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. 
  
 This is indeed a valid concern, but see further below. 
  
 > powerpcspe, kfreebsd-amd64, kfreebsd-i386 and ia64 were until recently 
 > actively maintained in ports. 
  
 The difference for me is that these have no stable branches, so once 
 they disappear from ports they have no concerns for their continued 
 support in existing systems (as they cannot be upgraded any longer 
 anyway). 
  
 > >... 
 > >   * 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. 
  
 This is the current and existing way where the tooling automatically 
 picks up the changes and automatically communicates that to maintainers. 
  
 > 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. 
  
 So, I've been thinking about this concern, and the problem with this 
 suggestion is that then either lintian would need to be modified to 
 mark specific architectures as deprecated (independently from dpkg), 
 or both dpkg and lintian (and any other arch tables consumer as well) 
 would need to be modified to convey when a certain arch is deprecated. 
  
 But if things need to be modified anyway, I think we should instead 
 modify the tool that is at the root of the problem, which is dak. 
 The problem is that dak is using the definition of present arches from 
 the dpkg in the host installation it is running on (whatever that is), 
 instead of a dpkg matching the target suite the upload is being uploaded 
 to. 
  
 This also has had the other consequence of needing to wait until an 
 arch defined in a dpkg in stable, before some references to new arches 
 can be added, which also seems rather inconvenient. 
  
 So, for now I've queued powerpcspe for removal for my next push (and 
 as I mentioned earlier in the thread, if someone has appetite in the 
 future to revive it, and support for gcc and glibc gets reinstated, 
 I'm happy to restore support for it in dpkg as well). And then I'll 
 ask the ftp-masters how to improve the dak vs dpkg arch situation. 
 (And if this cannot be easily improved we can always revert the 
 removals before the forky release.) 
  
 Hope, that cover the concerns. 
  
 Thanks, 
 Guillem 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2)