The beta of the new and improved itch app is out for testing

I'm happy they got rid of the tabs, I always found them very annoying.

Only the DEB packages. Can't install, so… Thanks, but no thanks!

Only the DEB packages. Can't install, so… Thanks, but no thanks!

The stable release has RPMs and even a repo. Don't know why that's not the case for the beta.

The stable release has RPMs and even a repo. Don't know why that's not the case for the beta.

Hmm, maybe so, maybe… When I tried to download the "stable" version I was prompted to "itch-23.6.3-amd64.tar.xz" tarball.

On the second thought, this all "DEB/RPM" thing is totally wrong. In general a PC can have multiple users (e. g. "family PC" ) and while some of them might use itch.io, others do not so this client should be installed per-user, not system-wide (needless to say a user might not be local admin).

Tarballs are all around better (or "*.sh" scripts if one prefers automatization).


Last edited by Alm888 on 11 Jul 2018 at 4:31 pm UTC

The stable release has RPMs and even a repo. Don't know why that's not the case for the beta.

Hmm, maybe so, maybe… When I tried to download the "stable" version I was prompted to "itch-23.6.3-amd64.tar.xz" tarball.

On the second thought, this all "DEB/RPM" thing is totally wrong. In general a PC can have multiple users (e. g. "family PC" ) and while some of them might use itch.io, others do not so this client should be installed per-user, not system-wide (needless to say a user might not be local admin).

Tarballs are all around better (or "*.sh" scripts if one prefers automatization).

...wut. well if you don't want actual packages that integrate with your system libraries, you could always try those fancy snaps or flatpaks. Many package managers allow non root installs or "user" mode installs. Packages exist as they are the most logical approach for users of a distribution. Why package all the libraries for each when you can share them. It may be ages until there is a clear "winner" for a univeral approch. I actually loathe firing up other package managers instead of using apt/yum/pacman. Using manual installers / shell scripts gets oflur of hand when the number of items increases.

tried it with raft and valheim. works.

...wut. well if you don't want actual packages that integrate with your system libraries, you could always try those fancy snaps or flatpaks. Many package managers allow non root installs or "user" mode installs. Packages exist as they are the most logical approach for users of a distribution. Why package all the libraries for each when you can share them. It may be ages until there is a clear "winner" for a univeral(sic) approch(sic). I actually loathe firing up other package managers instead of using apt/yum/pacman. Using manual installers / shell scripts gets oflur(sic) of hand when the number of items increases.

Wut?! I seriously begin to think that there is a "Package Approach" sect.

We do not need any "winner" in the "DEB/RPM/WHATEVER wars". Ordinary user should not even know about this.

From a user's viewpoint it is completely irrelevant what package system his/her distro is using. The user in question must see "xxx updates available. Update the system?" and click "Yea, sure!" That's all! Have you ever tried to install *.deb or *.rpm package manually? I have. It does not work! I mean, doudleclicking on it does not work. Best case, some dialogue window appears and asks permission to install, but if the package in question has dependencies then -- BAM -- the process fails. Because there are no mechanisms for dependency solving without repositories. "Command line" (terminal emulator) and manual downloading of required packages from some site like this are in order. This is BS.

From an administrator's viewpoint it is serious security breach to install some unsigned (or self-signed with shady keys) software in system-critical portions of the filesystem ("/usr/bin", "/usr/lib64" etc.) probably adding third-party open keys as trusted in the process. This is total BS!

User oriented entertainment software should not be installed system-wide!

And in case someone wondered, even user-level installed software can be added to auto-loading during startup and applications menu (AKA "Start Button"), see XDG specification.

Wut?! I seriously begin to think that there is a "Package Approach" sect.

This might come as a shock, but for most of us, Linux is not a religion.

From a user's viewpoint it is completely irrelevant what package system his/her distro is using. The user in question must see "xxx updates available. Update the system?" and click "Yea, sure!" That's all!

Yes, exactly. This is one of the strengths of a modern Linux distro. Updates are less intrusive than in Windows and mostly just work.

Have you ever tried to install *.deb or *.rpm package manually? I have. It does not work! I mean, doudleclicking on it does not work. Best case, some dialogue window appears and asks permission to install, but if the package in question has dependencies then -- BAM -- the process fails. Because there are no mechanisms for dependency solving without repositories. "Command line" (terminal emulator) and manual downloading of required packages from some site like this are in order. This is BS.

Last time I tried, deb files were handled correctly in both Ubuntu and Mint, as their default "software stores" and (my preferred alternative) the gdebi-gtk helper application are both perfectly capable of checking and downloading dependencies. And of course they won't let you install a package with broken deps. They also check and notify if a newer package is available in the default repositories. I haven't given a proper chance to rpm-based distributions in years, so I wouldn't know if their usability is worse these days.

From an administrator's viewpoint it is serious security breach to install some unsigned (or self-signed with shady keys) software in system-critical portions of the filesystem ("/usr/bin", "/usr/lib64" etc.) probably adding third-party open keys as trusted in the process. This is total BS!

Sure, a user can mess up their system if they install third-party packages, but if you're an admin to a bunch of users you can't trust, just don't let them install software. And for the users who you're not in control of, let them do whatever the hell they want with their systems.

Package managers obviously solve more problems than they create. Giving up and making people manage their own software does not solve anything. Games are a special case of software, but this is why we have frontends like the itch.io app and Steam. Both basically only install a bare-bones setup system-wide and most of the actual client and all the games are installed in user directories.

User oriented entertainment software should not be installed system-wide!

Agreed, but in the end, in a single-user gaming system this doesn't make much of a difference.

Last time I tried, deb files were handled correctly in both Ubuntu and Mint, as their default "software stores" and (my preferred alternative) the gdebi-gtk helper application are both perfectly capable of checking and downloading dependencies. And of course they won't let you install a package with broken deps. They also check and notify if a newer package is available in the default repositories. I haven't given a proper chance to rpm-based distributions in years, so I wouldn't know if their usability is worse these days.

That would be ideal, but we are not living in the Ideal World. For the sake of research I tried to download LibreOffice from its official site which is notorious for distributing the suite in dozens of small packages (41 in the base bundle, to be precise) and unpacked it in Ubuntu 16.10 (that's what I currently have in my VM, or, to be particular, it is regular Ubuntu but with Unity removed and XFCE installed, so more akin to Xubuntu).

• The first question is "And which of these packages shall I doubleckick?".


• OK, I've chosen "libobasis6.0-base_6.0.5.2_amd64.deb" (it sounds as good as any).


• Fine, some window appeared and after a minute of waiting warned me it is a 3rd party software and can contain non-free components (yeah, sure, this knowledge will come in handy :D ) and a button labeled "Install" (not really, it is localized).


• I clicked the button and… nothing! Not even an "ERROR!" message or something telling me what's gone wrong.


• At this point any regular user just reinstalls Windows, but I'm a nerd and know "magic" command sudo dpkg -i *.deb and use it in the directory with all the packages.


• It installs, proving that without "command line" nothing can be installed.

Please note, the VM does not have Internet connection, so everything needed was in that directory but GUI application failed to notice it. So, alas, the "*.deb" distribution method is just total BS without repositories.

Sure, a user can mess up their system if they install third-party packages, but if you're an admin to a bunch of users you can't trust, just don't let them install software.

Just what type of person are you? A tyrant??? No, no, no! Users should be able to install needed software (not just games, it could be engineering software like Blender, OpenFOAM or FreeCAD) locally (i.e. to their own home directory without any explicit permissions). Besides, a good app must not demand to be "installed", instead it should be usable from any directory (unpacked, of course) and contain every library it needs bundled with it (or use only common libs).

Giving up and making people manage their own software does not solve anything.

As I said, a user should not "manage" anything. Only 3 simple steps: 1) download; 2) doublelick, Next, Next, Next, OK (fewer "Next" steps => better); 3) Play. That's all. If a developer truly wants to be sure the game is up to date, it must build-in the update function in the game.

Yes, it is a Windows-like approach, but it works and it is well known to all ex-Windows users. No matter how repository approach can be "ideologically and conceptually superior", this must not stand in the way of ease of use.

Games are a special case of software, but this is why we have frontends like the itch.io app and Steam.

And, judging by the Windows™ practice, soon we will have frontends managing frontends (with all those 15 or so different "clients", like "Battle.net", "Origin", "Uplay", "Paradox Launcher" etc. trying to update everything what was and was not asked for and constantly hogging RAM).

Both basically only install a bare-bones setup system-wide and most of the actual client and all the games are installed in user directories.

Yeah, we all know about fabulous "Steam Runtime" dedicated to free us from "DLL-Hell"… eew… "Dependency Nightmare" while have not been updated since 2013.

But whether to use clients or not is entirely different topic.

Last time I tried, deb files were handled correctly in both Ubuntu and Mint, as their default "software stores" and (my preferred alternative) the gdebi-gtk helper application are both perfectly capable of checking and downloading dependencies. And of course they won't let you install a package with broken deps. They also check and notify if a newer package is available in the default repositories. I haven't given a proper chance to rpm-based distributions in years, so I wouldn't know if their usability is worse these days.

That would be ideal, but we are not living in the Ideal World.

I wasn't talking about ideals. I was telling you about my experience with installing third party debs. But of course third party packages might be all sorts of broken, which is why they should be avoided.

For the sake of research I tried to download LibreOffice.

And immediately you do something silly. Why would you not use the distro provided packages instead? You're just looking for trouble here, even going for a huge piece of software that's bound to get complicated, then failing to follow the install guide provided by the developer. Sure, the install process is needlessly user-hostile (if you consider going to the terminal a big no-no), but that's entirely up to them, not the package management system.

Sure, a user can mess up their system if they install third-party packages, but if you're an admin to a bunch of users you can't trust, just don't let them install software.

Just what type of person are you? A tyrant???

No, just pointing out that you either trust your users to do the right thing, or stop them from doing the wrong thing. And of course I meant "stop them from installing system-wide", not that you should by some magical means stop them from installing stuff in their home directories. Nothing stops developers from creating installers or tarballs of course, but the benefits rarely justify the support hell, especially for FOSS software. It's easier to maintain packages in official repositories usually.

Besides, a good app must not demand to be "installed", instead it should be usable from any directory (unpacked, of course) and contain every library it needs bundled with it (or use only common libs).

Yeah, we all know about fabulous "Steam Runtime" dedicated to free us from "DLL-Hell"… eew… "Dependency Nightmare" while have not been updated since 2013.

Can't decide, huh? You imagine games would keep updating their libs if they provided their own? The runtime was a semi-successful attempt at providing a stable target "standard library" for games to rely on. The implementation is far from perfect, but game devs are not forced to make use of it so why not.

But whether to use clients or not is entirely different topic.

Yes it is. And I remember very well how much you love Steam from previous comment threads. :P

And immediately you do something silly. Why would you not use the distro provided packages instead?

Please, stop discussing other's silliness when you do not have all information at hand, OK?
Just this time, I will explain. There are reasons:

• My main distro (Fedora) has some strange ideas about license purity (or just plain bad taste), so distro-provided software is often assembled with multiple functions disabled;


• Even if the previous isn't the case, often distro-provided software is not up to date (this is true with basically every distro for some package or another) and manual downloading from developer is the first solution;


• It was you who made a statement that "*.deb" distribution is totally intuitive and Quote "Last time I tried, deb files were handled correctly in both Ubuntu and Mint, as their default "software stores" and (my preferred alternative) the gdebi-gtk helper application are both perfectly capable of checking and downloading dependencies." End Of Quote (Remember those words?), so I showed an example where it is totally not the case.

You're just looking for trouble here, even going for a huge piece of software that's bound to get complicated, then failing to follow the install guide provided by the developer. Sure, the install process is needlessly user-hostile (if you consider going to the terminal a big no-no), but that's entirely up to them, not the package management system.

OK, using the link… reading:

Open a terminal.
Change the current directory to the location of the .deb packages:
cd ~/Downloads/LibreOffice_6.0.x_Linux_x86_deb/DEBS

or for the 64 bits version:
cd ~/Downloads/LibreOffice_6.0.x_Linux_x86-64_deb/DEBS

(No need to write everything: use Tab ↹ to autocomplete the command line, or copy and paste with the middle-click mouse button)

Finally, install all .deb packages:
sudo dpkg -i *.deb

First, a terminal! For a newbie, yeah, that should work just fine!
Second, I did exactly as was described!
What was your point in calling me doing silly actions or looking for trouble? This somehow was meant to prove your point of "DEB/RPM" distribution being intuitive and user-friendly? Or are you thinking I am stupid? Sorry, I do not get the point there. And I am not amused! :><:

Can't decide, huh? You imagine games would keep updating their libs if they provided their own?

Yes, they would. I see no technical difficulties for software to download and overwrite its own components, like this is done by Firefox and (was done while it was active) "Battle Worlds: Kronos", for example.

The runtime was a semi-successful attempt at providing a stable target "standard library" for games to rely on. The implementation is far from perfect, but game devs are not forced to make use of it so why not.

It was never successful. One of the most common solutions on Steam to launch the game that does not work (because of the Steam Runtime libraries are incompatible with current kernels and system libs) is to run Steam in "Native" mode. And developers time and again acknowledged in their interviews that while at the beginning they were trying to target SteamOS™ (with its software) at the end they found out it was easier to just target Ubuntu.

And I remember very well how much you love Steam from previous comment threads. :P

Whethe I like Steam or not is irrelevant to this topic. :S:

And immediately you do something silly. Why would you not use the distro provided packages instead?

Please, stop discussing other's silliness when you do not have all information at hand, OK?

I didn't mean to upset you. Sorry about that. I'll do my best to avoid inflammatory language.

Even if the previous isn't the case, often distro-provided software is not up to date (this is true with basically every distro for some package or another) and manual downloading from developer is the first solution;

I'd argue that this depends on distro. On Ubuntu the first solution is to look for a trusted PPA, and on Arch it might be to look for a suitable AUR package. Package quality can differ, but at least it integrates with the package manager. And of course, it's usually us more experienced users who'd even care about having the latest version of software. Common stuff like browsers tend to be kept up to date in supported distro releases anyway.

It was you who made a statement that "*.deb" distribution is totally intuitive and Quote "Last time I tried, deb files were handled correctly in both Ubuntu and Mint, as their default "software stores" and (my preferred alternative) the gdebi-gtk helper application are both perfectly capable of checking and downloading dependencies." End Of Quote (Remember those words?), so I showed an example where it is totally not the case.

I do remember those words, and you seem to have misinterpreted them. I just tried again and installing debs manually using gdebi seems to work just fine. Trying to install one that has broken dependencies gives a clear error message and prevents installation, and installing the dependency first makes the error go away as expected. I wouldn't go as far as to say this is all perfectly intuitive of course. But neither is downloading and extracting a tarball or downloading an .sh installer, marking it executable and so on until the user has a basic understanding of Linux and their desktop.

First, a terminal! For a newbie, yeah, that should work just fine!

Did you miss this part in what you quoted from me: "Sure, the install process is needlessly user-hostile (if you consider going to the terminal a big no-no), but that's entirely up to them, not the package management system." Like I said, nothing to do with apt/deb, just the way the libreoffice packager decided to do it. Maybe they didn't expect a new user to look for and try a manual install. Fair enough I guess. You don't sound like a newbie to me.

Second, I did exactly as was described!
What was your point in calling me doing silly actions or looking for trouble? This somehow was meant to prove your point of "DEB/RPM" distribution being intuitive and user-friendly? Or are you thinking I am stupid? Sorry, I do not get the point there. And I am not amused! :><:

I do not think you're stupid or silly, just pointed out that you picked a bad example. And you didn't follow the instructions to the letter if you tried to install an individual package by itself. Though I still don't see why any normal user would install libreoffice manually on Ubuntu when the system packages are fairly recent and there's even an official PPA.

Can't decide, huh? You imagine games would keep updating their libs if they provided their own?

Yes, they would. I see no technical difficulties for software to download and overwrite its own components, like this is done by Firefox and (was done while it was active) "Battle Worlds: Kronos", for example.

Whether there are technical difficulties or not has very little to do with the fact that game devs tend to stop updating their dependencies at some point. And if they want to, they can just as easily override Steam runtime libs with their own local ones as needed. These approaches are not incompatible and use of the runtime is not enforced.

The runtime was a semi-successful attempt at providing a stable target "standard library" for games to rely on. The implementation is far from perfect, but game devs are not forced to make use of it so why not.

It was never successful. One of the most common solutions on Steam to launch the game that does not work (because of the Steam Runtime libraries are incompatible with current kernels and system libs) is to run Steam in "Native" mode. And developers time and again acknowledged in their interviews that while at the beginning they were trying to target SteamOS™ (with its software) at the end they found out it was easier to just target Ubuntu.

Ubuntu is an officially supported Steam target platform so this makes perfect sense. I've never bypassed the runtime myself btw, but then again my gaming box is Nvidia/Intel and runs Mint, so I'm not exactly in the minority. Also, I said semi-successful, not successful. There's a difference. I have seen the problems this can and does cause for some users, especially on unsupported distributions.

...wut. well if you don't want actual packages that integrate with your system libraries, you could always try those fancy snaps or flatpaks. Many package managers allow non root installs or "user" mode installs. Packages exist as they are the most logical approach for users of a distribution. Why package all the libraries for each when you can share them. It may be ages until there is a clear "winner" for a univeral(sic) approch(sic). I actually loathe firing up other package managers instead of using apt/yum/pacman. Using manual installers / shell scripts gets oflur(sic) of hand when the number of items increases.

Wut?! I seriously begin to think that there is a "Package Approach" sect.

We do not need any "winner" in the "DEB/RPM/WHATEVER wars". Ordinary user should not even know about this.

From a user's viewpoint it is completely irrelevant what package system his/her distro is using. The user in question must see "xxx updates available. Update the system?" and click "Yea, sure!" That's all! Have you ever tried to install *.deb or *.rpm package manually? I have. It does not work! I mean, doudleclicking on it does not work. Best case, some dialogue window appears and asks permission to install, but if the package in question has dependencies then -- BAM -- the process fails. Because there are no mechanisms for dependency solving without repositories. "Command line" (terminal emulator) and manual downloading of required packages from some site like this are in order. This is BS.

From an administrator's viewpoint it is serious security breach to install some unsigned (or self-signed with shady keys) software in system-critical portions of the filesystem ("/usr/bin", "/usr/lib64" etc.) probably adding third-party open keys as trusted in the process. This is total BS!

User oriented entertainment software should not be installed system-wide!

And in case someone wondered, even user-level installed software can be added to auto-loading during startup and applications menu (AKA "Start Button"), see XDG specification.

The entire point is sane management. I suppose I can't argue with you. GPG keys exist for a reason. Sure someone software is convenient as a binary or archive. If I wasn't on mobile. Are you a devop/RHEL/Admin/Hadoop devop? Thanks I'd where I come from. Manually installed software is not what you want, so I can't agree there. Non-signed manual installation of RPMs is insane. You shouldn't be installing things like that anyway if you are going the manual approach. Yum local install exists as well. There is no war, not sure where that was picked up on. For games, I can see some merit for a contained/flatpak type approach. Overall, not using something* to manage software is exactly why bitrot was coined a term. Unfortunately, we still have old software that goes unmaintained. Sigh.