Hi, On 21.5.2025 20.54, John Paul Adrian Glaubitz wrote:
On May 21, 2025, at 4:16 PM, Eero Tamminen <oak@helsinkinet.fi> wrote: So to start, here are the things that are, and are not, relevant for me _on m68k_. I.e. _personal_ opinions. First some general principles, and then few examples.
...
Any thoughts on the above principles?The problem is that you assume that we can easily build and maintain a subset of Debian packages without investing a lot of time and effort.
I have no clue how that works, so my naive thought was that one could just supply some kind of a package name "skiplist", and builders would skip packages in that.
However, I do not intend to maintain a custom version of Debian. I want to build the vanilla version of Debian unstable because I do neither have the time nor the resources to roll my own version of Debian.
>
And using vanilla Debian unstable means having to build all of these packages that you are trying to avoid because you think they’re bloated or useless.
The idea wasn't to customize Debian or its packages, just not (even try to) build some of the packages for the m68k package repo.
Is there some documentation on why it won't work? ---Support for such list seems rather useful feature for the ports architectures, to skip packages that won't build as-is, or with trivial fixes, and for which nobody has declared interest (so that there would be a motive to fix non-trivial issues with them).
As to how that would work in practice, I would imagine that "skiplist" provided for builders would need to include also all packages that depend from given non-desirable package => there need to be some helper scripts to maintain it.
Those helper scripts could generate full "skiplist" from hand-maintained smaller one, add everything depending from them, and check that list against a hand-maintained whitelist, to verify that deps haven't changed so that a package that somebody actually wants to use on m68k, would be skipped.
And, as for Rust, an increasing number of Python packages such as python-cryptography embed Rust code, so the decision whether we should support Rust or not has already been made.
Right, quite a lot of packages depends on that, and even more on Rusted librsvg2.
While package dependencies, especially build ones, can quickly get out of hand, scripting I discussed above, would help in pointing out all implications of dropping or including specific packages. I.e. provide full facts for discussion on whether to drop or include specific (e.g. language) package for a m68k port subset.
- Eero