Evaluate releases distribution

[bebehei]

After discussing with @tsipinakis the release schema, I posed myself a yet unanswered question. How should dunst get distributed?

As we only want to maintain the current release with patches, I think it's unfair for the user and also contraproductive for all, not packaging the current dunst release for common distros. Users either have to manually install it to get an up-to-date dunst.

For distros like Arch and Debian, these problems are a small burden. For arch there is no need and for Debian, there is no real need, as they have an ingenious system for their versioning.

But it might be a good thing for Ubuntu to provide a PPA, as many only install the latest LTS to not update every 6 months, and actually do not want to have an old dunst version.

So, what are possible solutions?

• Solely Ubuntu:
  • If we think, we don't want to do any extra effort, I might at least create an official PPA for Ubuntu.
• One approach for all:
  • There are also some other approaches to create a "package" like AppImage or Flatpak (there is also AppStream?!).
    • It bloats the size of dunst package
    • It works at least with AppImage, as you can copy the dbus service file manually into $HOME/.local/share/dbus-1/services
• Use OpenSuse Build Service for this and provide a variety of packages. At least albertlauncher has its repositories there and his work looks quite good. Albeit I question, why he has Archrepos there.

---

I've put it onto 1.3 milestone. I want to have this question answered for me before the next release. I don't require this to be answered positively, but to be answered and reasoned well.

[tsipinakis]

As we only want to maintain the current release with patches, I think it's unfair for the user and also contraproductive for all, not packaging the current dunst release for common distros.

I'd argue the opposite:

• While it's true that only the latest release will be supported this obviously doesn't mean that if something serious like a security vulnerability hits we won't at least publish some official backported patches.
• Maintaining the existing version of dunst inside distributions falls into the responsibilities of the downstream maintainers usually via backporting existing patches from upstream, not for us.

For distros like Arch and Debian, these problems are a small burden. For arch there is no need and for Debian, there is no real need, as they have an ingenious system for their versioning.

But it might be a good thing for Ubuntu to provide a PPA, as many only install the latest LTS to not update every 6 months, and actually do not want to have an old dunst version.

You're contradicting yourself here: You're calling Debians versioning system ingenious while in the next sentence blaming ubuntu's system.

as many only install the latest LTS to not update every 6 months

Debian releases one major version every 2 years and they are supported officially for 3 years and up to 5 years via the LTS program, similar to ubuntus.

While these distributions do support the software they include both have very strict guidelines on what changes can go into stable, when, and for what reason. You can't just push a bugfix release and expect it to make it there. For example the debian developers reference states

Extra care should be taken when uploading to stable. Basically, a package should only be uploaded to stable if one of the following happens:

• a truly critical functionality problem
• the package becomes uninstallable
• a released architecture lacks the package

[...]

Changing anything else in the package that isn't important is discouraged, because even trivial fixes can cause bugs later on.
[...]
Uploads to the oldstable distributions are possible as long as it hasn't been archived. The same rules as for stable apply.

---

So, what are possible solutions?

If we think, we don't want to do any extra effort, I might at least create an official PPA for Ubuntu.

Possible but personally I hate the PPA system with a passion. So much could go wrong.

But do you really want to do all the work making sure dunst works fine with all available ubuntu versions as well as new ones as they come out?

One approach for all [...]

While I've heard of flatpak and the line I've never used them so I don't have a proper opinion on them. But I think we should avoid using less known methods since it makes it unlikely someone will use them - at this point it's easier to just build from source.

[bebehei]

Maintaining the existing version of dunst inside distributions falls into the responsibilities of the downstream maintainers usually via backporting existing patches from upstream, not for us.

Yes, but my goal is not the existing version of dunst. My goal is the latest version with almost zero effort. This has a simple reason: People can't come to the bugtracker and ask about old stuff.

Yes, the could install dunst manually via make && make install, but for non Unix Gurus, this can be quite hard. (Why do all these projects have special installation scripts, like https://get.docker.com/? Because these are easy! And yes, these are devilish, but most ppl ignore these warnings)

If you provide a repo, you do not have to handle any make calls and missing -dev packages. You just run apt-get upgrade, pacman -Syu, etc.

You're contradicting yourself here: You're calling Debians versioning system ingenious while in the next sentence blaming ubuntu's system.

In general yes, but there's a small detail. Ubuntu does not provide an equivalent to the debian testing release. If you're on testing, you get the latest dunst (which of course had to travel through sid at first). There is no such equivalent of Ubuntu. You either can use a stable snapshot or an old stable snapshot. On Debian you can choose between testing and stable and if you choose stable you can still fine-tune the version via apt-pinning.

as many only install the latest LTS to not update every 6 months

Debian [...]

Well, that does not apply to debian. It was meant for ubuntu.

But do you really want to do all the work making sure dunst works fine with all available ubuntu versions as well as new ones as they come out?

Well, I wouldn't set the standards of debian stable there. As long as the package builds fine in the PPA, I assume it's ok. Also, most of the introduced bugs are then mostly from upstream.

While I've heard of flatpak

I've researched appimage yesterday (flatpak and appimage have fundamental differences), but appimage did not suffice me. AppImage's pro is, that you just have a single bundle and it works with any Unix. But therefore, AppImage includes all required libraries in the file. So, this will only work after #334 is solved. Also, I don't know how easy it is to update an AppImage.

Flatpak's advantage is, that it provides an appstore and therefore you could easily update dunst. Con: you need the actual flatpak system package/binary first.

---

Off topic:

Possible but personally I hate the PPA system with a passion. So much could go wrong.

Oh, tell me more!

[probonopd]

I've researched appimage yesterday (flatpak and appimage have fundamental differences), but appimage did not suffice me.

Please elaborate. If you have questions, AppImage developers are on #AppImage on irc.freenode.net.

Also, I don't know how easy it is to update an AppImage.

Please check https://github.com/AppImage/AppImageUpdate.

[bebehei]

@probonopd There are a few features I personally miss. Currently, some example scripts look quite hackish and the fact that everything is done in your local dir and nothing like $DESTDIR/PKGDIR is exported in your env make such scripts cumbersome.

Also packaging it currently with Appimage makes no sense, as we would have to bundle GTK+, making the package for factor 1000 (sic!) bigger. We want to get rid of that first.

[knopwob]

My opinion (and it's just my opinion, since you're doing most (all) of the work, you have more say in this than I do):

I dislike installation paths that circumvent the systems package manager. It just adds more stuff you can forget when trying to keep your system up to date (things installed via ruby gems or python pip comes to mind).

I haven't looked into it very deeply but http://openbuildservice.org/about/ (https://build.opensuse.org/) seems to be interesting in order to get native packages for the most popular distributions without having to setup a build environment for everything by ourselves.

[bebehei]

I dislike installation paths that circumvent

I agree with you by 110%.

But I measure the make commands worse than an AppImage. So it might not be the best, but it's at least better. (Given that the update should be supereasy).

Regarding OBS: I did not find any docs according OBS and the WebUI is IMHO fucking complicated. I think that OBS is actually a good thing, but I guess it's hard to master.

[probonopd]

@probonopd There are a few features I personally miss. Currently, some example scripts look quite hackish and the fact that everything is done in your local dir and nothing like $DESTDIR/PKGDIR is exported in your env make such scripts cumbersome.

What are you referring to? AppImageKit does not compile your sources. What you put inside an AppImage is entirely your own business.

Also packaging it currently with Appimage makes no sense, as we would have to bundle GTK+#

Factor 100, really?

Depending on how exactly you do it and which target systems you are targeting, you may even get away without bundling Gtk+.
I think at this point it's safe to assume that Gtk+ 2 is available on every target system in an ABI-mature enough version. As for Gtk+3 just target something like the oldest still-supported LTS (e.g., 14.04 trusty) and most likely the resulting binaries should run on most Gtk+ 3 shipping distributions. Just avoid API-instable, bleeding-edge Gtk+ 3 stuff.

[bebehei]

I did not find any docs according OBS

Well, OBS != build.opensuse.org and clicking on docs there resolves to the Opensuse docs and not the general OBS docs (which I needed).

the WebUI is IMHO fucking complicated

Well, it still is. Some things are very untuitive. But it's getting easier with the docs and IRC support and the ability to copy some stuff from albert. And also have a neat command line client (osc).

But do you really want to do all the work making sure dunst works fine with all available ubuntu versions as well as new ones as they come out?

Well, I wouldn't set the standards of debian stable there. As long as the package builds fine in the PPA, I assume it's ok. Also, most of the introduced bugs are then mostly from upstream.

Also, if it's not an upstream issue (which would be our work anyways), others can "branch" our dunst package and make a request, which is the equivalent of a PR. insert woohooo gif here I'm missing this in the AUR.

[bebehei]

So, I've worked inside my own project and got deeper into OBS now.

It's still the case, that the documentation lacks. But I had been able to create valid repositories for Arch, Ubuntu, Debian and Fedora. At the end of the day, it's supereasy to update multiple repositories with just one push.

It should be also possible to trigger an update/rebuild via git push and have dunst nightlies.

The support offers X11:dunst project namespace. The X11 might be a bit misleading. I also wanted to request something like desktop:dunst, but wayland is also categorized under X11 there.

At the current point, I have to polish packaging files, as I have copied them plain from the distros with minimal changes.

[probonopd]

It's still the case, that the documentation lacks. But I had been able to create valid repositories for Arch, Ubuntu, Debian and Fedora. At the end of the day, it's supereasy to update multiple repositories with just one push.

And AppImages!

[bebehei]

And AppImages!

OBS supports requests 😜

[probonopd]

https://git.io/obs-ai 💯

[bebehei]

I give up on OBS. Why? OBS simply lacks the feature to make patches to the package and increasing the package revision number. The set_version service simply hardcodes it to 0 (also the revision should actually start with 1).

This is bad. The workaround would be to not use set_version and set all revision numbers manually in the package repository. But this renders the whole _service file useless and requires changes for simple package bumps in every file. No, that's not my job. That's OBS' job! It creates much more work and errors. The gain of having one source to create native packages for multiple distros vanishes completely.

This is actually symptomatic to OBS. There are more mistakes of this sort.

I don't want to go through the hassle of creating a PPA for Ubuntu. Going through the hassle and feeding multiple distros was cool, but not just for a single distro, I don't primarily use. I pull the "Pull requests welcome" card here.

snapcraft: This is the first well documented tool in this thread! It was really a joy reading the docs. Looking at the yaml files, these look quite clean and it even has a special DBus interface (but I don't know how it works in conflicts with notify-osd). It works a bit like docker. Downside: Additional daemon required. Also I estimate the cut of the dunst user set and snapcraft user set minimal.

flatpak: Docs are quite good. When reading them, you can see the GApplication stuff shining through. Downside: Also requires a daemon. Also it looks like flatpak apps are mainly targeted for GNOME desktop and dunst can't run there. And like snapcraft, I expect the user set to be quite low.

AppImage: In theory, the stuff should work. I've got a clue how it works and dunst can be injected into the system. AppImage is quite open and allows to install the dbus service file by our own via shell script. I also like the idea to have one Exe for all. But I'm reluctant to create it. Like OBS it lacks a proper tutorial and more important: A reference. There are plenty of use cases listed in the wiki. But how are these supposed to help without knowing which command does what? It's like putting the actual source code into your comany's wiki and saying to your colleagues "it's documented".

---

I don't require this to be answered positively, but to be answered and reasoned well.

I wanted to provide packages, but I believe the outcome is not worth the effort.

[probonopd]

I give up on OBS. Why? OBS simply lacks the feature to make patches to the package and increasing the package revision number.

Might be a bug. Ping @adrianschroeter

[bebehei]

Might be a bug.

No. It's not working on OBS for debian and Arch. OBS is doing it right only for RPM. He already pointed this out in IRC.

[Samueru-sama]

Hey is there some interest in providing an appimage? I made one here

It bundles its own ld-*.so so it works on any linux system and not just like most appimages that only work on certain glibc systems.

I also make use of the ARGV0 variable set by the appimage runtime to determine which binary to launch since dunst has several.

[bynect]

Hey is there some interest in providing an appimage? I made one here

It bundles its own ld-*.so so it works on any linux system and not just like most appimages that only work on certain glibc systems.

I also make use of the ARGV0 variable set by the appimage runtime to determine which binary to launch since dunst has several.

Seems interesting. Maybe you can integrate this and send a pr?
So we can automatically create an app image on release

Also by multiple binary you mean dunstify and dunst, correct?

[Samueru-sama]

Seems interesting. Maybe you can integrate this and send a pr? So we can automatically create an app image on release

Thanks, will try, just refactored the script a little bit to deploy everything manually and not rely on external tools as much as possible.

Also by multiple binary you mean dunstify and dunst, correct?

dunstify, dunst and dunstctl, if you ln -s *.AppImage {dunst,dunstify,dunstctl} the appimage knows which one to launch based on the name of the symlink, similar to busybox.

On top of that by default it will always launch dunst if ARGV0 doesn't match anything, and passing the flag --ctl or --notify changes that to dunstctl or dunstify.