Back

But why do we need a hell at all? The good old ZIP file with a single directory containing everything still works on either OS. In fact, if you rename that directory to .app, it's pretty much how MacOS has worked since OSX. The advantages of putting everything in a single directory (with subdirectories if needed) are several.

- Everything just works
- Uninstalling is as easy as removing the directory
- If you use paths relative to the executable, that directory can be placed anywhere, even on a USB stick. Windows users call that a "portable program".

So why don't we do it? Why would anyone want dependency hell?

(2/2)

@leeloo dependencies are still useful security-wise. I'm not saying all libs are critical, but if you look at the history of security issues, many times parsing libs like PNG, JPG, XML, XZ and more have been exploited to crack into systems. And you still have even more security sensitive ones like SSL or the libc.

Depending on system libs that can be updated to close security holes (specially on systems where updates are only critical patches) is important. The rest could be static à la golang.

@mdione
And while we are at it, do you think people go hunting for new versions of those(non-system) dependencies that a single program requires before an upgrade to the program requires them to install a new version?

And if the new version is incompatible, do you think they keep track of when it's safe to remove the old version? I know I have a ton of old libraries installed that probably aren't in use, but no idea which ones they are. If they were included in the directory of the program that required them, they would be gone when I uninstall that program, or upgraded with the
program.

Heck, I don't even know if anything still depends on GTK-1, don't tell me that having that installed as a dependency somehow makes the version I have installed more recent than if it was included and removed with whatever depended pn it.

@leeloo well, the distro I use takes this very much in account; If you have an update to a library, it's a critical patch and it's compatible with the version it's replacing (because it _is_ the same version, just with an(other) patch). It also knows what packages you manually asked to install and which were automatically installed as dependencies. Once all packages depending on package A have been removed, and A was autoinstalled, A is removed.

@mdione
And how does it know how to manage random stuff that installs who-knows-where using one of several different installers or some kind of script that may be bash, python, make, cmake or any of the other make wannabes, without someone manually telling it how?

I have my own Arch-style build script for creating Slackware packages, and while it's less work than slackbuild, it's still way too much manual work.

Meanwhile, on the laptop, I just drag a program into Applications, done.

@leeloo personally I try to keep those to a minimum, that's why I also chose a distro that has a huge software collection. I also use some 3rd party packages, but in general they're clean enough. If they aren't, I remove them and go for something else. And if it's going to be not very clean, I try to read their install scripts; if they're too intrusive, I tend to go for something else.

1/

@leeloo

I have even rejected very good tools only because they only release in Docker form and I have no guarantees those docker images will get security patches. Exposing insecure stuff to the internet is a no-no for me. And trying to read their onion layers of docker images, not always clearly published, or including stuff I already have installed in a more trusted way, was too much.

At worse I give them a directory in /opt or /home/me/src/system which I can easily rm.

/end

@leeloo

PS: yes, packaging is a lot of work.

@leeloo

let me expand: what .app files do is "here, have this binary blob, you have no idea what's inside, you might if you spend enough time on it, but you won't be able up patch its components". Docker images are kinda similar. Not my cup of tea. Granted, I work and one of my hobbies is setting up servers, but to me security at the desktop level is also important.

@mdione
I don't know why you are talking about docker. To me, docker is part of the problem (making everything too complicated - or in the case of docker, WAY too complicated, when the solution is simple.

.App files are no more a binary blob than any other executable. The .app "file" is actually a directory, the file manager just pretends that it's not.

And again, having a bunch of software lying around that nobody remember why it was installed in the first place or which programs may break if you upgrade them does not improve security. Having the library upgraded with the software does, even though its not perfect (because then you may have multiple versions of the same library with different holes).

@leeloo I mention Docker because it's the closest to app dirs that's also well spread.

The "nobody remembers why it was installed" part: as I said, the package manager does. If you want to remember why you installed, say darktable or stellarium, there are ways to that too.

1/

@leeloo

And yes, a big point of dependencies is having a single or few versions of libraries so the security management is simpler. Having a lib upgraded with the software might solve some security issues, but it's not a security only patch and brings new features, it might introduce new ones.

/end

@mdione
Upgrading your Debian system does not fix the 27 security holes in libfoo that was only availabe from Sourgeforge.

@leeloo The 27 security holes in libfoo will still be there, whether it's in the .app directory, or in /opt. Someone has to fix that; it's either you, the developer, or the packager. I personally prefer not to install libfoo unless it's strictly necessary. And I have done it, or had to deal with the consequences of someone else doing it.

@mdione
The developer is already doing it for every sane system. Their build scripts might even become shorter if they didn't need an exception because on Linux, dependency hell has become a "best practice".

My point is that the software you use is more likely to get updated than the dependency, and the dependency is definitely more likely to stay around after it's no longer needed when we leave it to the end user.