melonDS-emu
Why not provide a .deb file?
i'm to saying to add it to debian or ubuntu repo but creating .deb file is as simple as creating structure like this
melonDS-deb/
├── DEBIAN
│ └── control
└── usr
└── share
├── applications
│ └── melonDS.desktop
└── melonds
├── melon <- the executable
└── melon.svg
DEBIAN/control
Package: melonDS
Version: 0.1
Maintainer: luk
Architecture: arm64
Description: nds emulator
Depends: libcurl4-gnutls-dev,libpcap0.8-dev,libsdl2-dev,qtbase5-dev,qtbase5-private-dev,qtmultimedia5-dev,libarchive-dev,libzstd-dev
Note. my system is arm64 so this is an arm64 variant usr/share/applications/melonDS.desktop
[Desktop Entry]
Name=MelonDS
Comment=NDS emulator
GenericName=MelondDS
Exec=/usr/share/melonds/melon
Icon=/usr/share/melonds/melon.svg
Type=Application
Categories=Emulator;Game;
Keywords=nds;
and running dpkg-deb --build melonDS-deb/
if not provide it directly maybe add a simple script to create it automatically makeDeb.sh
echo "compile"
cmake -B build
cmake --build build -j$(nproc --all)
echo "clear previous attempt"
rm -rf melonDS-deb/ 2>/dev/null
rm melonDS-deb.deb 2>/dev/null
echo "create the dir sctructure"
mkdir melonDS-deb
mkdir melonDS-deb/DEBIAN
mkdir melonDS-deb/usr
mkdir melonDS-deb/usr/share
mkdir melonDS-deb/usr/share/applications
mkdir melonDS-deb/usr/share/melonds
echo "create control file"
echo "Package: melonDS" > melonDS-deb/DEBIAN/control
echo "Version: 0.1" >> melonDS-deb/DEBIAN/control #this probably can be integrated with cmake
echo "Maintainer: luk" >> melonDS-deb/DEBIAN/control
echo "Architecture: `dpkg --print-architecture`" >> melonDS-deb/DEBIAN/control
echo "Description: nds emulator" >> melonDS-deb/DEBIAN/control
echo "Depends: libcurl4-gnutls-dev,libpcap0.8-dev,libsdl2-dev,qtbase5-dev,qtbase5-private-dev,qtmultimedia5-dev,libarchive-dev,libzstd-dev" >> melonDS-deb/DEBIAN/control
echo "create desktop file"
echo "[Desktop Entry]" >> melonDS-deb/usr/share/applications/melonDS.desktop
echo "Name=MelonDS" >> melonDS-deb/usr/share/applications/melonDS.desktop
echo "Comment=NDS emulator" >> melonDS-deb/usr/share/applications/melonDS.desktop
echo "GenericName=MelondDS" >> melonDS-deb/usr/share/applications/melonDS.desktop
echo "Exec=/usr/share/melonds/melon" >> melonDS-deb/usr/share/applications/melonDS.desktop
echo "Icon=/usr/share/melonds/melon.svg" >> melonDS-deb/usr/share/applications/melonDS.desktop
echo "Type=Application" >> melonDS-deb/usr/share/applications/melonDS.desktop
echo "Categories=Emulator;Game;" >> melonDS-deb/usr/share/applications/melonDS.desktop
echo "Keywords=nds;" >> melonDS-deb/usr/share/applications/melonDS.desktop
echo "copy rest of the files"
cp build/melonDS melonDS-deb/usr/share/melonds/melon
cp res/melon.svg melonDS-deb/usr/share/melonds/melon.svg
echo "build the deb file"
dpkg-deb --build melonDS-deb/
If it indeed is that simple to build a .deb package it might be something we can look into. Currently, CI builds require at least Ubuntu 22.04 (or I guess the equivalent Debian release) to run because they are built against Qt 6, so we'd have to make that clear with the packaging somehow.
As an outsider looking in, I don't think this is necessary? MelonDS is already officially packaged as both a flatpak and appimage, along with a native executable being provided. With that much already provided, I don't see any benefit to also packaging it as a .deb file. Doing so would both invite people to ask for packages for other distributions and also lead to issues where certain distros either don't provide a dependency or ship an incompatible variant of it, which would have never been an issue if they just used one of the already provided packaging formats.
As an outsider looking in, I don't think this is necessary? MelonDS is already officially packaged as both a flatpak and appimage, along with a native executable being provided. With that much already provided, I don't see any benefit to also packaging it as a .deb file. Doing so would both invite people to ask for packages for other distributions and also lead to issues where certain distros either don't provide a dependency or ship an incompatible variant of it, which would have never been an issue if they just used one of the already provided packaging formats.
as i said if not provide a deb including script that makes a deb (that nicely integrates with the rest of the system) works too i literally provided the script that does exactly that
i know what flatpak's r but i'm not the biggest fan of them since on my system they cause a lot of issues with gpu (not nvidia) not working and other stuff i know the sandbox and all but common, do we really need to protect ourselves from an emulator?
also cmake provides an option for building deb's so can look also into that honestly if someone is willing to make a PR adding script that makes package for their distro what's the problem? it shouldn't affect amount of issues since ppl already build it from source without it
just tell me where to put that script and i can make a PR
.deb's just suck, they are the package of a package manager but without the actual package manager. They don't have any guarantee to work outside of the specific distro and distro version you built the .deb against (so e.g. some Ubuntu 22.04 .deb doesn't have any guarentee to work on Ubuntu 23.04 nor any guarentee to work on Debian). You need to create many .deb files to get some wide range of support (and even that support is limited to apt-like distros such as Debian and Ubuntu and their forks) and those will inevitably break.
If you want a build without flatpaks or appimages, either have someone host it as some package on some PPA or whatever so a proper package manager can use it, or just go build it yourself.
if you build it on your system with this script, it will work on your system no need to host deb file anywhere