Pretty sure you can by doing "dpkg --root=$HOME -i mypackage.deb" or something like that, long time ago I used dpkg, but it should be possible with some flag.

Otherwise I agree, Flatpak is a breath of fresh air!

As a sibling comment already noted, using "--root" doesn't always work and a q&a mentions the problems:

https://askubuntu.com/questions/28619/how-do-i-install-an-ap...

https://serverfault.com/questions/23734/is-there-any-way-to-...

For example, rust's cargo can compile and install applications into `~/.local`, but it's pain to keep them up to date, so I prefer to use same tools from my OS (Fedora) distribution repo instead.

edit: should have written "where does dpkg put the files of the package ?" or "where does that put the Deb's files ?", sorry.

       --root=dir
              Set the root directory to directory, which sets the
              installation directory to «dir» and the administrative
              directory to «dir/usr/local/var/lib/dpkg».

For instance I always do `python3 -m pip install --user wormhole` or `pip install --user wormhole` instead of sudoing my way to permissions hell. Python apps get installed in $HOME/.local/bin, so no cruft for other users.

But stuff installed with deb packages often have hard coded pathways and assumptions of where and how their files are run.

So I think it's fair to ask in reply to someone implying that `dpkg --root=$HOME -i mypackage.deb` is as clean/same as a flatpack behaviour "It installs only in my profile, so another user on the same machine doesn't have access. You can't do that with a .deb!"... It's fair to ask "where do those files in the deb package go ?" because if it works as implied (no pollution of the OS) I am certainly going to start testing installing things that way.

It's worse because you're likely to install more packages using something like Flatpak than you would by downloading random binaries or building from source. That wantonness isn't justified given the current state of security on Linux.

(I'm just regurgitating OP: "Flatpak and Snap apologists claim that some security is better than nothing. This is not true. From a purely technical perspective, for apps with filesystem access the security is exactly equal to nothing. In reality it’s actually worse than nothing because it leads people to place more trust than they should in random apps they find on the internet.")

... what makes you say that ? if I want to run something, it'll run one way or another no matter how hard the "system" wants to prevent that. Even if it's patch.exe downloaded from a 2004 russian website.

No. It doesn't. You still need to trust the people who package the thing.

A working packaging system would give the user ultimate power to manage access to resources by each app. Overriding or mocking, if the user so decides, whatever access does the app believe to need. Flatpack does not give you such power, it removes this power from you and assigns it to the packagers. Thus, not only it doesn't work: it works against you!

EDIT: The "dependency hell" issue is separate, and is solved more easily by distributing static binaries.

Flatpak and Snap have never claimed to solve the trust issue though. Flatpak allows you to add your own repositories and thus developers can package their own applications. So if you trust the developer enough to run their software, you should be able to trust them to package their own app with.

Flatpak/snap is somewhere in between where on the main repos (eg. flathub.org) anyone can publish a package for anything without being affiliated with upstream. It incentivizes users to just search for the app name and download whatever comes up as a result. That's a pattern we've known to be broken for years: from Windows users downloading the first link Google suggests (usually a sponsored link bundled with spyware/adware) to Android users downloading anything the Play Store suggests (usually spyware, see how many flashlight apps there are and what permissions they require). F-Droid in the Android ecosystem strikes a balance because there is strong community vetting for all packages published, so it's like a distro-agnostic repository following the distro packaging threat model.

I believe there are ways to mitigate those issues (eg. namespace enforcement on flatpak) but i don't think downplaying them is doing any good.

To make things worse, Flathub changed the way they display "Publisher" field for a flatpak. Which says whether a package was published by Flathub maintainers, Upstream developer or somebody else in Flathub. Now instead of saying who, they just say a "See details" link under Publisher field in flathub.org for a flatpak. That link which in turn directs me to a github page and I am still unsure who the hell uploaded that flatpak.

Before, they used to say Upstream developer's name or say "Flathub maintainers" which means Flathub team uploaded the flatpak making it easier verify who uploaded the flatpak. But now it is making it more difficult. This has been the most pissing thing about Flatpak other than the security issues and problems which keeps coming up about Flathub every now and then. Why would you change something that is so crucial when it is working?

Cos now, I could package a software which is not in Flathub and it would just say "See details" instead of my name. This provides the illusion of trust. Cos if it were to show my name there, more people would've been like.. who the hell is this guy and do a check on me (I used to do that). But now, If I could slip through Flathub checks and provide malicious flatpak, majority of the folks will still install cos most of them are using Flatpak for convenience. Not security and performance.

Want proof? Just scroll up and you will see someone saying he don't care even though agrees to the things in the blog post. He just don't care. :shrug:

If anything, isn't the flatpack situation better in that regard because the end user is more likely to have a sandbox?

I personally see no upside to shoving an unpaid third party between user and developer.

I think F-Droid is a good example of striking a balance between those two extreme models. Their existence enforces community vetting of apps as well as somewhat-reproducible thanks to their standardized build infra, which are two major wins.

I personally have much more trust in such schemes (such as guix/nix) because i don't necessarily trust all of the developers of apps i use not to get hacked, and i believe enabling one-click updates to every user of an app without review is a dangerous pattern for security.

Such maintainer will be kicked off from distribution.

> and ignore developer wishes (like "please stop distributing this ancient unmaintained software without this warning that says it is ancient and unmaintained")

Developer wishes are developer wishes. User wishes are more important. If package has a maintainer, then it IS maintained.

You can use any distribution developed by developers (do you know any?) if you dislike maintained distributions and share experience with us.

ORLY? What's Kurt Roeckx[0] up to these days? Oh right, he's the Debian Project secretary, despite famously crippling RNG in OpenSSL.

> Developer wishes are developer wishes. User wishes are more important.

You mean like the wish to get up to date software directly from the developer without waiting for some third-party middleman to get around to updating the repo?

> You can use any distribution developed by developers (do you know any?) if you dislike maintained distributions and share experience with us.

Such a beast doesn't seem to exist in the Linux world, so I just don't use Linux. Linux Desktop's abysmally low market share may or may not be related.

[0] To be fair to Kurt, he wasn't the only one who didn't see a problem removing those lines and he did ask around first. It is an understandable mistake and I don't mean to crucify him.

Debian did this, they said oops and moved on. Packagers suck as developers, they apply patches they don't fully understand to solve problems they don't understand on codebases they don't understand.

You shouldn't need to trust either. Just the sandboxing system of your OS.

The Linux kernel is not at a point of allowing this kind of fine grained sandboxing or mocking of APIs. I'm guessing because it's a significant undertaking. I'm sure as more features become available in the Kernel w.r.t. sandboxing Snap and Flatpak will definitely utilise them.

Yes, and very big: Debian maintainers need to build a reputation for years to gain upload rights, meet in person, sign keys, and the packages are peer reviewed my multiple persons.

Plus, packages spend time in release freeze being tested by a large userbase before a distro is released.

How is this any different than sudo apt install foo?

"Flatpak: Linux application sandboxing and distribution framework " [0]

"It is advertised as offering a sandbox environment in which users can run application software in isolation from the rest of the system." [1]

The whole point of a sandboxing environment is that you can run applications that do not want to be sandboxed. The flatpack proposition is directly contradictory with this basic requirement, in that it requires the application to be flatpacked to begin with.

[0] https://github.com/flatpak/flatpak

[1] https://en.wikipedia.org/wiki/Flatpak

As a user, I'd like to give Krita/Libreoffice permissions for ~/Documents and Tor Browser permissions for ~/Downloads. I don't know yet of a user-friendly method to achieve that.

[1] https://docs.flatpak.org/en/latest/sandbox-permissions.html#...

The filesystem permissions are a bit more fine-grained than "all of home or nothing". Your two examples are already possible to achieve by granting filesystem access to xdg-documents or xdg-downloads.

Signal let's you save attachments anywhere on disk, but only if you manually navigate to ~/Downloads, does it actually save (in a way visible and accessible outside of the app). You just gotta know.

I forgot what exactly the problem was with Vscode(/ium), but it also has a catch like that. You just gotta know.

Flatpak turns out to be the best compromise between distribution and cross distro compatibility, but there's still some low hanging fruit that could be improved.

Flatpak aware apps (like the ones I develop, or any on elementary OS since flatpak is the native packaging format there) tend to just work.