Hi Charles On 3/13/26 01:33, Charles Plessy wrote:
Dirk, the list at the end includes your architecture-dependent packages that directly or transitively depend, recommend or suggest r-cran-utf8. Can you architecture-restrict them?
This isn't needed for Suggests (like Dirk already mentioned). For Recommends, I'd say it's a touch call as we (ambiguously) don't allow it by policy, but nothing checks on it and I wouldn't want to drop architecture support for a binary because its Recommends isn't available on that architecture. Worse case one can annotate the Recommends with an architecture qualifier, but that feels a PITA and just busywork (which seems like counteracting the goal of your campaign). And for completeness this also isn't needed for Build-Depends, as once the binaries are removed on architectures where the Build-Depends and reverse packages are removed, those architectures can't build the binaries anymore and things are OK from the archive point of view.
On 3/12/26 13:29, Charles Plessy wrote:Control: fixed 1127349 1.2.4-1 Control: fixed 1127631 1.1.0-1Le Thu, Mar 12, 2026 at 02:53:53PM +0100, Paul Gevers a écrit :We told you before you started with this effort of dropping architecture support that you needed to be prepared for the removal bugs. You ignored that
- I replied that I will group them by batches covering some large branches
of the r-cran-* dependency network, because I expect that hundreds
of individuals removal bugs are not welcome. I added that I expect
that I only can do so when all the packages in the same bulk removal
are architecture-restrited. I asked for advice on debian-devel about
bulk removal bugs.
Not on d-devel, but: Message-ID: <[email protected]>
"""So, I think for you mass upload it's probably the easiest to start with leaf packages and then work your way up the stack, unless you make special arrangements with ftp-master.
"""As I understand it, you work alphabetically and you have not made special arrangements with ftp-master.
removing binaries of non-arch-restricted packages is pointless because
builds-will reupload the binaries
... unless Build-Depends are removed at the same time and thus no longer can be satisfied on that architecture. The buildds can only upload what they can build. So, had you arranged support from ftp-master, you only needed to do the annotation at the bottom of the stack.
- I announced (maybe not in this thread, but on this list), that I made a
first pilot test (#1128383). That bug was closed this week by the Archive
Operation team.
That was quite some time after you started your endeavor. Maybe a pilot *before* would have been useful?
If that is not acceptable with you, please let me know with precise instructions on what removal bug(s) I must fill and what was wrong in my reasonning.
I haven't checked, but I stand with Dirk in his remark that these packages shouldn't be removed for Suggests (and per my remark above, also not for Recommends).
Paul
OpenPGP_signature.asc
Description: OpenPGP digital signature
