[zrm]

> I want all of the QT libs embedded in the package.

I don't understand why anybody wants this.

Libraries should have major versions and the latest of each major version should be compatible with anything using that major version, because that's what major version means for a library. You might then need to have more than one major version of the library installed, but any two applications using the same one should be able to use the same copy, and then have it maintained by one person in one place.

If every package has a separate copy of every library, people have to maintain them all separately. When that library has a security update, you now have to update five dozen packages instead of one or two, and have a security vulnerability if any of the maintainers don't keep up in a timely fashion. Which not all of them will.

> I want the proprietary app in a container.

People want containers to be magic but they're actually a hard problem. You want the app not to be able to do anything you don't want it to but still be able to do everything you do want it to.

A backup app that can't read my files is useless; it can't back them up. But it shouldn't be able to modify or delete them. But it should be able to modify its own state. It shouldn't have general network access but should be able to communicate with the backup server, which might have to be specified by the user and not the package maintainer. It doesn't need access to the GPU or the ability to use gigabytes of memory, but it does need to be able to transfer a lot of data over the network, but the data it transfers is lower priority than other network packets.

That requires the person configuring the app's container to have both detailed knowledge of the app and detailed knowledge of the container system. It's common for this not to be the case.

And that's why containers are a mess, not anything to do with the package manager, which should have little to do with the container system outside of packaging the app's default container configuration with the app.

[schmichael]

> I don't understand why anybody wants this.

Because creating debs is largely a completely distinct undertaking from the dependency and build management the developer of an app does.

Bundles, whether via images or static binaries, allow app developers to distribute their app against the exact dependencies it was developed against -- potentially using the same build system.

There's obviously tradeoffs to each approach, which is why I don't think there's one right way to distribute every bit of executable code on a system.

> People want containers to be magic but they're actually a hard problem.

I work on a container orchestrator, so I understand some of the difficulty. :) Mobile apps are years ahead of desktop apps when it comes to containerizing in a user friendly way. Obviously there's plenty of work still to be done, but the problem is far from intractable and the benefits are enormous.

[im3w1l]

Mobile apps are a hellscape. It's an example of how wrong things can go. Apps treat their privilege model as a license to abuse all their privileges as much as possible.

Ability to read Contact list? Location access? Great let's upload it all to the Googbook analytics for data mining our customers.

[schmichael]

But what's the alternative? No MAC and every app has all user privileges by default like most Linux distros?

I would argue the concept has not failed, just the implementations have fallen short. And for good reason! It's an extremely complex confluence of cutting edge technology, UX, security, privacy, etc. It's been improving, and surely the open source community can do it even better (or at least with a greater focus on privacy).

[nikau]

It would be nice to have a prompt when the phone asks for phone book access:

Allow Deny Fake

The Fake would just have generated names and numbers to pollute their data mining.

[ric2b]

> Libraries should have major versions and the latest of each major version should be compatible with anything using that major version

Should, but accidental breaking changes are a thing. Plus flatpack more or less solves this by having standard runtimes (base collections of libraries/dependencies that flatpack apps target) that get security updates.

> That requires the person configuring the app's container to have both detailed knowledge of the app and detailed knowledge of the container system. It's common for this not to be the case.

With Snap, developers explicitly ask for the permissions they need and the approval process evaluates if it makes sense for that app to have those permissions (and by default or not).

[zrm]

> Should, but accidental breaking changes are a thing.

They're a thing either way. If a library has a security update that breaks your app, your choices are to have a security vulnerability or to have a broken app, until somebody fixes whatever is broken in either the library or the app. The only good option is to fix the breakage quickly -- or do better testing to begin with.

> Plus flatpack more or less solves this by having standard runtimes (base collections of libraries/dependencies that flatpack apps target) that get security updates.

At which point they might as well be their own packages so that you only have to install one copy of that version, since they're the same for every application anyway.

> With Snap, developers explicitly ask for the permissions they need and the approval process evaluates if it makes sense for that app to have those permissions (and by default or not).

This is not a solution to the hardness. If the developer doesn't understand the permissions model well enough to know to ask for a given permission they need, the app is broken. If they ask for permissions they don't need, either the approvers need to understand the app well enough to know it doesn't need that, or they approve permissions it doesn't need.

It doesn't get you out of needing somebody who understands both the app and the permissions model well enough to be able to correctly specify which permissions the app needs and doesn't.

[ric2b]

This permissions model and approval process already works in mobile app stores. Yeah, if the developer doesn't understand the permissions model they ship a broken app, so what? Are we supposed to expose our computers so that incompetent developers don't break their own apps accidentally?

[zrm]

> This permissions model and approval process already works in mobile app stores.

The permissions are too coarse-grained. Flashlight apps ask for ridiculous permissions and get them. Some permissions are "too dangerous" so you can't have them even if the user trusts you completely and you have a good reason, which makes certain apps impossible. It's rubbish.

> Yeah, if the developer doesn't understand the permissions model they ship a broken app, so what?

So then they err on the side of requesting too many permissions, which is made even worse when they're coarse-grained.

> Are we supposed to expose our computers so that incompetent developers don't break their own apps accidentally?

What Linux does, to start, is to not package things from incompetent developers. If your app is nothing but a fork of Thunderbird that uploads all the user's contacts to your server, Debian isn't going to package that because there's no demand for it. But you could get the equivalent thing into the app stores, because things get there when developers push them there, not when packagers pull them there.

Then the Linux apps have the source code for anybody to view and modify. If the app was originally written to do something problematic, you can modify the app not to do that before distributing it.

That makes the permissions model much less important, because the problem of malicious apps is much reduced and all you need it for is containing bugs.

Your app isn't supposed to access the network, so you assert as such. Then if it has a bug or somehow gets compromised, the system can at least prevent it from accessing the network.

But you don't have such an aggressive tension between false positives and false negatives because more of the false positives got eliminated through having access to the source code and not packaging garbage apps to begin with. If a Debian packager doesn't restrict the app from accessing the network even though it didn't really need to, probably doesn't matter anyway. If an app store does the same thing, that was the only thing preventing the app from sucking up all your contacts and sending them to a third party server.

[afiori]

> I want the proprietary app in a container.

People want containers to be magic but they're actually a hard problem. You want the app not to be able to do anything you don't want it to but still be able to do everything you do want it to.

As I see it the problem that containerization in snaps and similar solution is the isolation of system configuration.

I agree that permissions are an hard problem and honestly I am not sure how much they are relevant for snaps, but what is theory is feasible is that installing a snap could be completely and reversible.

I believe that is true of flatpack at least.

[zrm]

> As I see it the problem that containerization in snaps and similar solution is the isolation of system configuration.

If you drop your app's config file in /etc/ and nothing ever touches it, isolation isn't really buying you anything. If something does, that could still be what you want to happen.

For example, suppose there is a P2P app that can operate either by having you forward a port from your router (which is not always available) or by operating as a Tor onion service. To do the latter it has to modify Tor's configuration so that it allows incoming connections to the application's port. It's something you want to happen, it's something the package can clean back up again when it's uninstalled, but that doesn't work if the two otherwise independent applications have their configurations isolated from each other.

So it's still the permissions problem.

[afiori]

I would say that more than having your own config be left alone, the complex case is when two different applications want to mess up a third party configuration.

Software repos as a whole in part exist to solve and harmonize these cases.

[alkonaut]

> people have to maintain them all separately.

Yes. I think most people (most people don't run Linux in any form) would like to think of their system as having a collection of independent applictions, not a set of libraries.

If people are expected to "maintain", or even understand, the concept of shared libraries, then I think the system is only geared to power users and tinkerers (the current user base more or less).

[zrm]

The people who maintain the libraries are not the users, they're the library package maintainers.

If you move the libraries into the application packages then the package maintainers for every application also have to maintain every library they use, duplicating the efforts of one another. The users then suffer when they do it poorly because they don't have the time or domain expertise to maintain multiple third party libraries in addition to their own application.