[baldfat]

> Upstream can't be expected to release packages for every distro (if any).

This isn't provide distro specific packages this is provide the one extra file over macOS and Windows.

Also this is for the health of the Linux environment.

That is why we have RPM and Deb they work for MANY distros and if your outside that then the source is there for aa build. One day appimage, flatpak or Snap will make this easier.

[darklajid]

No, RPM and Deb files don't work for many distributions.

Yes, the formats are shared (say, RPM for Fedora, RedHat, Suse). But the resulting binaries aren't (usually, automatically - you might get lucky of course) compatible.

The whole point of distributions is to build a system. Fedora and Suse are on different schedules, make different decisions about updates, might run different versions of the libraries your package (here: pinta) depends upon.

Your RPM file often isn't even usable between different releases of the same distribution. So just adding a random RPM wouldn't make sense. You brought up OBS elsewhere: One of the major reasons that thing exists is so that you can build packages .. for a list of target platforms. OBS is a service that uses a build recipe and upstream sources (pintas tarball) to spit out binary packages for various different environments and formats.

So one additional RPM file wouldn't do the trick here.

[baldfat]

I use OpenSUSE. The rpm's always work I might have to grab a dependency from somewhere or make a soft link, but 99% of the time they work. These are all the programs I use that I need to grab from RPM packages from their website RStudio (I use the preview version), Lightworks, Bittorrent Sync, and VS Code. Without RPM I would not get to use them period.

In the old dasy of Linux their would be a lot of issues but presently RPM and Deb works like a charm fro my uses.

I am hoping for appimage of flatpak to take over but for now RPM is my life blood to get things working.

If it is a niche program that won't be on the repos or it is updated frequently RPM is a very viable system.

[darklajid]

We disagree a lot, so I'm going to bow out after this one. Please be assured that I don't intend to poke you or offend you - I genuinely feel that you are missing some pieces of the picture.

RPMs don't work in a vacuum. Unless you bundle a statically built thing or something trivial (say .. a shell script) you reference dependencies. Those change between environments.

32bit/64bit machines differ. Ubuntu vs. Debian, Suse vs. Fedora. Builds for current versions of Ubuntu might not/will not work on older ones. You can only provide a (guaranteed to be working) rpm by having one per combination here, a la 'This is for Ubuntu FunnyName 32bit'. You understand that this explodes in complexity quite easily and quite fast.

Now, you're bringing up exceptions again and again (your system is 99% Suse provided packages I'd bet and you have less than a handful applications that you install manually. High profile apps maybe, but still: A few, compared to your distribution's packages).

I can't explain each and every case, but let's look at VS Code: They offer an RPM. That's true. But that's a 50MB file that depends on .. nothing, really. glibc and /bin/sh. All static. You're downloading a zip, more or less. Possible, but wasteful and not common. Download Atom and VS Code and you download Electron twice. You're also ignoring most of rpm's feature set here. This is not a good example for 'providing an RPM' (again, a tar.gz might provide ~the same~ if you ignore that this puts a .desktop file in the right place to create a shortcut to launch this thing. Extracting this to ~/opt for example would give you 99% of what this RPM package does).

For ~normal~ projects, providing packages is just not feasible and bundling projects into coherent ... packages (ahahaha) is what distributions are for, really. Debian knows that it patched library X and all projects using that library might need to be bumped as well. Debian can rebuild their own packages at the same time. Upstream projects cannot follow every distribution and update their '32bit Debian Jessy' build in a timely manner after the distribution changed some parts of their system.

appimage/flatpak etc. are basically doing what your VS Code example did again: A bundle of everything. 'Portable apps' in the Windows world. OS X bundles. In my world that's really a bad trade-off, although I understand the appeal in terms of simplicity. I personally feel that this comes with a high(er) risk for security issues and don't like the wasted space.

Back to pinta: They provide a _real_ package (actually they don't provide any binary package, they just link to a PPA they maintain, probably because they actively use that themselves?) with dependencies. Not a lot, but they actually define a real package. Not a complete bundle with a random file extension like VS Code. For pinta it would be more effort to create RPMs and the benefits aren't clear at all (just zypper install pinta or whatever you do on Suse).

Please ignore the file extension. RPM isn't RPM in these cases. Please don't claim that pinta mixes up Linux and Ubuntu. There's no reason to get worked up ("I hate it when they do this") about this. They handle this the normal way, the standard way. I haven't seen Suse in action for ages, but I suppose you're either using KDE (likely) or Gnome (maybe). Both don't even offer any binaries (for Linux) as far as I'm aware.

vim doesn't offer RPMs either..

(On a side note: VS Code is completely available in the open for some time so it could be built the ~normal~ way using shared libraries for dependencies. Bittorrent Sync will always be a problem though)

[baldfat]

I certainly don't get worked up but I do use i3 and several KDE programs. I think your more right 5 years ago then where we are today with Systemd in our world the differences between distros is getting smaller and smaller. Once again the RPM I download work and they work for me.

I get "worked up" when the only thing offered is a ppa and a source :)