| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 26 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 60:43:51 |
| Calls: | 481 |
| Files: | 1,072 |
| Messages: | 96,081 |
Mono was orphaned last year, and I took over its maintenance because
I rely on it to run some non-free video games (not redistributable,
so not packaged into Debian), so I can unvendor the Mono runtime
shipped with these games and use the Debian-provided runtime instead.
What this means is that my interest as a maintainer is mostly focused
on the runtime binaries and libraries, to the exclusion of anything
related to using Mono as a development platform. Sadly this (the
development platform) is taking a big part of what the packaging is
about, and I end up working alone on something I have no real
interest in and get no fun from.
So at first I was simply thinking about removing mono-devel and all libmono*-dev libraries after Trixie release, keeping only the runtime packages. But I got some feedback from people who would really like
to keep the ability to develop Mono software on Debian, and would
rather keep these libraries packaged.
In addition, there are still 14 reverse build-dependencies on
mono-devel:
- cecil
- de4dot
- dnlib
- gnome-subtitles
- hexbox
- keepass2
- keepass2-plugin-keepassrpc
- log4net
- nini
- openmcdf
- opentk
- quickroute-gps
- repetier-host
- smuxi
Since I do not really have the motivation nor the skills to keep
maintaining this development platform, all of these would have to go
away if I stay alone in the so-called Debian Mono "Team".
On the other hand, if other people *really* want to keep the ability
to build Mono/C# software relying on Debian-provided package, I’m
more than willing to share the load and restore the "Team" part in
"Debian Mono Team".
Even if you don’t have time to dedicate to long term maintenance,
drive-by contributions would be most welcome. If the state of these
packages is improved, it would lead to a much lighter maintenance
burden afterwards, and might restore the motivation that I am now
lacking.
Here are examples of tasks that could be picked up and would help me
a lot:
- bugs triage, many are really old and might no longer apply to the
build of Mono currently shipped in Debian
- patches clean up, the current state is many patches maintained as
git branches and several others as diffs in debian/patches. I would
like the git-based ones to all be converted into individual diffs
tracked in debian/patches
- lintian clean-up (adding overrides is not cleaning-up), the current
tracker page reports 2 errors and 407(!) warnings
- maintenance takeover of orphaned Mono build-dependencies:
cli-common and libgdiplus
In addition, even if mono-devel is going to stay, another less
impactful removal I was planning is the alternative Boehm garbage
collector, in favour of keeping only the default SGen one. Would
anyone be missing this GC if it were to go?
If no one manifests any interest in helping with Mono maintenance, I
plan to start removing packages after the release of Trixie. Whatever happens, *nothing* is going to be removed from Trixie, but please
don’t wait until Forky is almost there before reacting. At this point
it is going to be far too late.
If I am to go further with the removal, I will open bugs against the
affected packages probably sometime around the release of Trixie.
PS: No need to keep all the CC emails if the discussion keeps going,
I only added them to send a ping to all people who manifested
interest on this topic or are maintaining a package that would be
affected by this removal. On the other hand, please keep me as CC, as
I am not subscribed to this mailing list yet.
If no one manifests any interest in helping with Mono maintenance, I plan to start removing packages after the release of Trixie. Whatever happens, *nothing*
is going to be removed from Trixie, but please don’t wait until Forky is almost
there before reacting. At this point it is going to be far too late.
If I am to go further with the removal, I will open bugs against the affected packages probably sometime around the release of Trixie.
As upstream has moved around a bit, wouldn't it make more sense for mono to package the dotnet repository for Forky instead?
My understanding is that debian mono is sourced from the mono-project repo [1], which is no longer maintained, but the wine-mono fork [2] has v6 going. wine-mono is distributed with Wine, but not packaged in debian. I know wine-hq will download mono and set it up (runtime .msi installer), never checked if debian wine downloads it or not.
(…)
For the runtime-only, maybe wine-mono could be a better upstream if you aim to keep it minimal at v6, but for the mono-dev side, dotnet v10 could be a better upstream.