Hi,
On 21.5.2025 20.54, John Paul Adrian Glaubitz wrote:
On May 21, 2025, at 4:16 PM, Eero Tamminen <[email protected]> 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
