Re: Debian subset suitable for m68k (was: Tuple and changes for m68k with -malign-int)

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