I would love to see an easier way to package DEB packages, since it requires a lot of effort at the moment compared to building and uploading packages to a user repository like the AUR and https://mpr.hunterwittenborn.com/. For example, I got UnityX working on Arch Linux/Manjaro within an hour without any issues (just had to write a simple PKGBUILD and upload it to the AUR). It would also allow a lot more software to be packaged by the community (like in Arch where most developers don’t package software but the community does). Snaps could be a viable alternative for Ubuntu and other distros, but people are limited to the highly-confined apps available in the Snap Store. Publishing classic snaps requires approval from the store admins. They do respond within a few minutes from my experience, but many people developing snaps feel that the store admins would take a lot of time or wouldn’t respond to them. I guess it would be ideal to have an extremely experimental and unstable repository for advanced users where they are allowed to upload a format similar to PKGBUILDs for building and installing the DEB packages directly on a user’s machine without any approval.
note that classic snaps are an exception that is not lightly granted because it gives full access to the host. they are only allowed for a certain set of packages and after a long winded review process from the security team (it is not a few minutes usually, but rather several weeks) … note also that classic snaps are extremely hard to package correctly, you need to mangle RPATHs of binaries so the shipped libs are found, make 100% sure your app does not accidentally access any libs from the host etc etc… while packaging (strictly confined) snaps is lots and lots easier than packaging a deb package and usually pretty straightforward, correctly packaging a classic snap is rather 10x harder than packaging a deb …
classic is also only granted for a few supported use-cases like compilers, IDEs or programming languages, you can see the (rather small) list at:
Hi @ogra 
Yeah, sure. That’s why I mentioned building/using something similar to the AUR rather than snaps for this purpose. I suggested having package build files similar to a PKGBUILD file which can be built on the user’s machine as a DEB and installed (similar to https://mpr.hunterwittenborn.com/ and https://gitlab.com/ubuntu-unity/unity-x/qckdeb).
well, you can always build strict snaps with confinement: devmode, that way you get the easy snap packaging without having to bother a lot with confinement.
these snaps can be uploaded to the store without any review but not be released to the stable channel which kind of corresponds to your “experimental and unstable repository”
I think this bit should target advanced users who can simply tweak the package and PKGBUILD-equivalent file and install it as well as inspect what the package is doing, apart from continuing to receive updates if they fixed a bug in the PKGBUILD and upstreamed their local changes or disable updates if they have tweaked the package and want to manually rebuild the package from a Git repository once in a while with their custom PKGBUILD file (like it is possible with the source variable). Also, I’m not sure if it’s possible to package a fully functional window manager (like i3) or a desktop environment (like Plasma) as a snap. I’m aware a few shells using Mir have been packaged as snaps, but most of them are extremely barebones unlike GNOME, KDE or XFCE (or even UnityX). I would love to see support for complete X11 desktop environments and window managers to be packaged as snaps. Guess the best way to implement this would be to use a tool like https://gitlab.com/ubuntu-unity/unity-x/qckdeb and compile and generate a DEB on the user’s machine which can then be installed (which can be done with a helper like yay). Installed Manjaro a few days ago on one of my machines to package UnityX for it and I just had to write the PKGBUILD file (https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=unityx) and upload it to the AUR by following https://wiki.archlinux.org/title/AUR_submission_guidelines. Would love it if something similar could be implemented for Ubuntu or if I could help out in implementing it, since I’ve already developed something called qckdeb along these lines (https://gitlab.com/ubuntu-unity/unity-x/qckdeb) which I use for packaging UnityX and its components.
https://github.com/ogra1/ubuntu-core-desktop-snap
you can actually do all the bits you described above with snap packages (i.e. packages built by the automatic build system all ship their snapcraft.yaml by default so you can easily rebuild them locally with a single command), snap has builtin strace, gdb and other debug features to “inspect what the package is doing,”
and last but not least you can always unsquashfs any snap file on your system. modify/patch it on disk and use snap try in the unpacked dir …
either way, i think we are getting off-topic for this thread and should do any forther snap discussions on the snapcraft forum
Oops, I was editing my post to include the Mir example and I think we both posted it together Mir is kinda buggy at the moment, so not sure if GNOME on Mir would be as stable as a desktop environment packaged as a DEB package.
Oh, I was mainly interested in being able to simply build a package from a Git repo like the i3-gaps-rounded-git package and other packages in the AUR by just downloading the PKGBUILD/snapcraft.yaml file and getting the source code and compiling the software when installing it on the user’s machine instead of the developer having to constantly update their package.
Sure @ogra, guess I’ll create a thread on the Snapcraft forum for the snap-related bits 
I like this reply. It makes a lot of sense.
When I have issues with a Snap, I always want to ask myself this question “would I prefer to have to dig out an obscure PPA, hope that it gets maintained, hope there is nothing nefarious in it or conflicts with other packages, and hope it gets updated on my next release upgrade?”
And usually, the answer I give myself is: “Ok I take the snap with its flaws”
What I mean is, I think Canonical heart is in the right place here. I see the vision and I see the goal. Unfortunately, Snaps are not perfect today and I also understand why users are unhappy. Users see that their perfectly working debs are taken away and exchanged for less performing and less optimized snaps. And, well, yes it makes sense to be less than happy about that.
Personally, I buy the vision so I encourage friends and people in my communities to use the snap. Then, if it is not as good as the deb, make sure to let the developers know and send constructive criticism for both the snap platform and the application to improve.
Also, not small thing, we are not talking Ubuntu only here. Snaps work in most distributions, so Canonical is spending time and money to bring applications to the whole Linux ecosystem. That is hard to beat. I take a bit of bumpy road to get there.
Those are not searchable or auto-updatable.
they should be searchable … but indeed you are correct that they will not auto-update
I’m actually trying to package my Node.js utility as a Snap. It can work with files like find and it’s quite disappointing that it can’t operate on files in /etc or /usr because of strict confinement. I wish there was something like snap run --allows-once-fs=/etc/my/dir my-utility do stuff