1. Forum
  2. Usenet
  3. LINUX.DEBIAN.PORTS.68K

  • Re: Debian subset suitable for m68k (was: Tuple and changes for m68k wi

    From Eero Tamminen@21:1/5 to John Klos on Wed May 21 16:20:02 2025
    Hi John,

    On 21.5.2025 4.59, John Klos wrote:
    As I pointed out years ago, you need to stop wasting effort on packages
    that aren't relevant anymore, due to bloat.

    There's no real point being made here. Which packages aren't relevant
    any more, due to bloat? Who decides?

    Decision part is IMHO rather obvious, it should be both users and
    maintainers together.

    It's good for maintainers to ask users for feedback on what matters on
    them, so that effort is not wasted on something that nobody uses. And
    also to ask help if some task is larger, to see whether there's enough
    interest (= help available) to make that effort actually worthwhile. If
    not, what's the point of maintaining something nobody cares (enough)?

    So next question is what are the best ways to reach users and get their feedback?

    Package statistics, bug reports and just asking on the mailing list(s)
    are first things that come to my mind, but others may have other
    suggestions.

    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.


    Relevant
    --------

    Base system, compilers, interpreters, misc tools, some graphics, and
    things shared between niche/retro communities (like m68k) in general.

    In my case, for example:
    - Kernel
    - Busybox
    - Gcc
    - G++
    - Lua
    - Python
    - La/TeX
    - SDL1
    - ScummVM
    - Wired networking
    - w3m, links, lynx etc
    - Small niche windowing systems
    - Slimmed-down Debian essentials


    Not relevant
    ------------

    Modern corporate backed software, and anything needing encryption or
    GPUs supporting GLES2+, I get enough of those on x86 Linux. They are too
    slow / large for m68k platform, and frankly boring, all something I try
    to avoid in my hobbies. :-)

    For example:
    - Java & C#
    - LibreOffice
    - Chrome/ium, Firefox, Webkit
    - Modern desktop environments (KDE, Gnome...)
    - libSDL v2 & v3, and things depending on them
    - Wireless & VPN support
    - Virtualization


    Potentially relevant
    --------------------

    Some of the new tech, especially when it relates to smaller setups and
    base system, and more lightweight GUI apps, might also be of interest at
    some point:
    - Wayland / Weston
    - Golang
    - Rust, Zig
    - Abiword, Gnumeric, Evince (non-Gnome versions)
    - LyX (LaTeX GUI)


    Any thoughts on the above principles?


    - Eero

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to All on Wed May 21 20:00:02 2025
    Hello Eero,

    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.


    Relevant
    --------

    Base system, compilers, interpreters, misc tools, some graphics, and things shared between niche/retro communities (like m68k) in general.

    In my case, for example:
    - Kernel
    - Busybox
    - Gcc
    - G++
    - Lua
    - Python
    - La/TeX
    - SDL1
    - ScummVM
    - Wired networking
    - w3m, links, lynx etc
    - Small niche windowing systems
    - Slimmed-down Debian essentials


    Not relevant
    ------------

    Modern corporate backed software, and anything needing encryption or GPUs supporting GLES2+, I get enough of those on x86 Linux. They are too slow / large for m68k platform, and frankly boring, all something I try to avoid in my hobbies. :-)

    For example:
    - Java & C#
    - LibreOffice
    - Chrome/ium, Firefox, Webkit
    - Modern desktop environments (KDE, Gnome...)
    - libSDL v2 & v3, and things depending on them
    - Wireless & VPN support
    - Virtualization


    Potentially relevant
    --------------------

    Some of the new tech, especially when it relates to smaller setups and base system, and more lightweight GUI apps, might also be of interest at some point:
    - Wayland / Weston
    - Golang
    - Rust, Zig
    - Abiword, Gnumeric, Evince (non-Gnome versions)
    - LyX (LaTeX GUI)


    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.

    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.

    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.

    If you think it’s worthwhile to maintain a custom Linux distribution for m68k, you are free to do that. However, it’s not the work I am interested personally.

    Adrian

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Eero Tamminen@21:1/5 to John Paul Adrian Glaubitz on Thu May 22 00:20:01 2025
    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 pa