ubuntu
Support installing local deb packages
There's no support for dealing with local packages yet. However 'snap-store' is supposed to handle those by default:
$ grep debian /usr/share/applications/defaults.list
application/vnd.debian.binary-package=snap-store_ubuntu-software-local-file.desktop
application/x-debian-package=snap-store_ubuntu-software-local-file.desktop
Do we have an alternative way of handling those for the time being?
Do we have an alternative way of handling those for the time being?
We can use gdebi or eddy for those, until the feature doesn't comes up in snap-store.
@soumyaDghosh , what is eddy, there are no package eddy in official Ubuntu repos :(
We can use
gdebioreddyfor those, until the feature doesn't comes up in snap-store.
@soumyaDghosh , what is
eddy, there are no packageeddyin official Ubuntu repos :(We can use
gdebioreddyfor those, until the feature doesn't comes up in snap-store.
Eddy is probably not in the repo.
I hope this is fixed soon. I love the look of the new snap store, but the Steam snap doesn't work with my Nvidia card yet. So I have been going to Steam website to get the deb to install. I installed gdebi to install the deb packages I needed.
Thanks for your hard work in making Ubuntu better and better.
In my opinion, it is absolutely essential that this problem is fixed for the next version of Ubuntu, in fact, I really think that the current version of Ubuntu should have the new store without this problem.
The most common thing is that a new user, to install Google Chrome for example, goes to the official website, downloads the binary and double-clicks to install. When he notices that it doesn't work he will be completely lost... As Ubuntu is considered one of the most important distros for new users, it is very important that this problem is resolved.
As an inspiration the previous incarnation of this app here had local deb side loading (it is still in the preview/edge channel to try) Alternatively we could eventually create a second app for only the deb and/or app image sideloading? Similar to how ot looks on Mac maybe? I mean, the code is still here:
https://github.com/ubuntu/app-center/blob/archive/main/lib/app/package_installer/package_installer_page.dart https://github.com/ubuntu/app-center/tree/archive/main/lib/app/common/packagekit https://github.com/ubuntu/app-center/tree/archive/main/lib/services/packagekit
🤷
https://github.com/ubuntu/app-center/assets/15329494/fdbc0d51-316b-4b38-aecf-bff7418f893d
In my opinion, it is absolutely essential that this problem is fixed for the next version of Ubuntu, in fact, I really think that the current version of Ubuntu should have the new store without this problem.
The most common thing is that a new user, to install Google Chrome for example, goes to the official website, downloads the binary and double-clicks to install. When he notices that it doesn't work he will be completely lost... As Ubuntu is considered one of the most important distros for new users, it is very important that this problem is resolved.
Agreed 100% - this is a core feature that shouldn't require the command line or other tools. Previous versions of the store allowed it to work seamlessly
Here is how it worked in the community driven app-center some months ago:
Bildschirmaufzeichnung vom 2024-01-05, 16-49-56.webm
Unfortunately we didn't have the capacity to work on this for 24.04, but it will be a priority for the next cycle!
This should have been fixed in the LTS version itself. An LTS version is supposed to be the most stable of all, and to just ignore it for two versions consecutively reeks of haughtiness, especially since as pointed out, Ubuntu is still considered the distro for beginners to Linux. And LTS versions are almost always recommended for such people. If they see such a half-baked system for installing apps in the OS widely recommended, it'll cost the reputation of not only Ubuntu but also the wider Linux world.
as an alternative Just do sudo dpkg -i debpackage.deb
altough they need to fix it asap.
This reminds me of old versions of Android where the native apps were so bad that you had to download third party apps with duplicate functionality. The same story happens here, you need to uninstall your new installer to download gnome-software, because it allows me to install the deb version of Google Chrome without using the terminal.
I think situations like this are one of the reasons for the growing hatred of Ubuntu, unfortunately. This is yet another situation that serves as an argument for those who think that Canonical is forcing the use of snaps.
From my point of view resolving this issue should have been a priority. If it wasn't possible to implement a solution in the App Center in a timely manner, then a tool like GDebi should have been provided by default.
The new Ubuntu looks really good, but these details, in my opinion, tarnish this release.
Okay everyone, as the creator of this project here, here is a warning:
[!WARNING]
Keep the off-topic and meta critique out of this github ticket!
If you want to give feedback, positive or negative, or want to make comments that are unrelated to the pure development of this application here, please do this on https://discourse.ubuntu.com/
Please keep in mind that we are all humans. This platform here is for developing software together. Thanks!
Speaking as the APT maintainer, let me outline a different path forward on the road to 26.04:
In 23.10, we enabled .sources files for PPAs, in 24.04 we enabled .sources files for the main Ubuntu repositories too.
My goal is to build on this foundation and provide an easy way to add 3rd-party repositories rather than packages, by extending the .sources format with some templating (so you can say "${OS_UBUNTU_CODENAME}" for example), and a field for listing packages to install.
Then 3rd party deb providers can ship complete standalone .sources files. And we can validate the sources files, possibly checking the repository URL and/or having a blocklist for signing keys, copy it to sources.list.d, and then offer to install the packages listed in the file.
The first stage of this is the easy apt add-sources command which takes an https:// url and does just that (not with any blocking ability so far, or ability to install packages). Revamping the sources management experience with a new deb822-focused flutter software source management app that can add new sources using those files, and maybe a curated list of default repositories, would be a lovely extension.
This bug report is getting some new attention by way of trade press. As an Ubuntu developer and member of the Ubuntu Technical Board, I want to weigh in on the bug.
In the short term, we should fix desktop-file-utils to not declare the snap store as a handler for .debs. It doesn't handle them, so this is clearly incorrect.
In the long term, I believe this bug asking for automatic desktop handling of .debs through the snap store should be won't fix.
Over a decade ago, we had forays into the use of extended attributes for tagging browser-downloaded files on the desktop, so that an extra verification step was required before executing downloaded files to protect users from accidentally running trojans.
But people seem to think that if those same trojans are wrapped in a .deb file, point-and-click'ing your way to executing those same trojans AS ROOT is perfectly fine.
Over the past decade, extras.ubuntu.com, then click packages, then snap packages have all had two main objectives:
- growing an ecosystem for third-party apps on Ubuntu, in recognition that putting software in the distribution directly will never completely address our users' needs for applications
- addressing the fact that .debs are a fundamentally unsafe format by which to provide third-party software.
Every third-party apt repository you enable on your system is an attack vector.
Every third-party deb you install directly on your system is an attack vector.
Every third-party app store you enable on your system is also an attack vector.
(The first-party app store - archive.ubuntu.com+snapcraft.io - is also an attack vector. But you're always going to have at least one, and it's assumed that as a user of Ubuntu this is the one you've opted in to.)
Any .deb you install can run arbitrary code at install time, unconfined, as root. It can also overwrite arbitrary files belonging to other core system packages, inject libraries into every running process using LD_PRELOAD nonsense, etc.
As a user, I NEVER install any third-party .debs on my system without first rigorously inspecting the control file for the package, its contents (file paths), and any maintainer scripts to verify that there's no funny business going on.
How do you expect to provide that level of safety in a GUI package installer for non-technical users?
Even if you trust the publisher of the .deb, how do you make sure that it hasn't been tampered with in transit to your system? Do you trust https? Should users in Iran trust it?
We should explicitly WONTFIX this. Installing third-party debs is a security minefield, and while we will never prohibit users from doing it, it is not something we should be explicitly enabling for non-technical users. There are much better ways that publishers SHOULD be distributing their software for Linux today.
I guess it's a "canonical error" 🍭 I guess that means that Ubuntu has been killed off, should be renamed, and is officially not based on Debian anymore.
desktop-file-utils bug opened here: https://bugs.launchpad.net/ubuntu/+source/desktop-file-utils/+bug/2063855
This bug report is getting some new attention by way of trade press. As an Ubuntu developer and member of the Ubuntu Technical Board, I want to weigh in on the bug.
In the short term, we should fix desktop-file-utils to not declare the snap store as a handler for .debs. It doesn't handle them, so this is clearly incorrect.
In the long term, I believe this bug asking for automatic desktop handling of .debs through the snap store should be won't fix.
Over a decade ago, we had forays into the use of extended attributes for tagging browser-downloaded files on the desktop, so that an extra verification step was required before executing downloaded files to protect users from accidentally running trojans.
But people seem to think that if those same trojans are wrapped in a .deb file, point-and-click'ing your way to executing those same trojans AS ROOT is perfectly fine.
Over the past decade, extras.ubuntu.com, then click packages, then snap packages have all had two main objectives:
- growing an ecosystem for third-party apps on Ubuntu, in recognition that putting software in the distribution directly will never completely address our users' needs for applications
- addressing the fact that .debs are a fundamentally unsafe format by which to provide third-party software.
Every third-party apt repository you enable on your system is an attack vector.
Every third-party deb you install directly on your system is an attack vector.
Every third-party app store you enable on your system is also an attack vector.
(The first-party app store - archive.ubuntu.com+snapcraft.io - is also an attack vector. But you're always going to have at least one, and it's assumed that as a user of Ubuntu this is the one you've opted in to.)
Any .deb you install can run arbitrary code at install time, unconfined, as root. It can also overwrite arbitrary files belonging to other core system packages, inject libraries into every running process using LD_PRELOAD nonsense, etc.
As a user, I NEVER install any third-party .debs on my system without first rigorously inspecting the control file for the package, its contents (file paths), and any maintainer scripts to verify that there's no funny business going on.
How do you expect to provide that level of safety in a GUI package installer for non-technical users?
Even if you trust the publisher of the .deb, how do you make sure that it hasn't been tampered with in transit to your system? Do you trust https? Should users in Iran trust it?
We should explicitly WONTFIX this. Installing third-party debs is a security minefield, and while we will never prohibit users from doing it, it is not something we should be explicitly enabling for non-technical users. There are much better ways that publishers SHOULD be distributing their software for Linux today.
I totally get what you're saying here and to a large extent agree with it. But what's the alternative? A skilled user will know enough to know whether they trust a third party .deb or not and can choose to install it or not as they see fit. An unskilled user, on the other hand, won't be prevented from installing a third party .deb, and in their frustration in trying to get it installed they probably won't be led to think more about "do you really trust this" by there simply being no graphical .deb installer. What they're going to do instead is Google some random blog site that will tell them to copy-paste commands into their computer, which they will then do (a security hole right there), and manage to get the app installed anyway without having done any security checks. Leaving a layer of frustration here will encourage insecure practices, not discourage them.
What really might help from a security standpoint is to allow the user to install a third party .deb through Ubuntu's software store (removing the "random instructions from the Internet" security hole), but also give the user a stern warning about the implications of what they're doing (and maybe even a link to some security-educating documentation). That way a user who's just trying to get Google Chrome working will be able to say "well... I do trust Chrome, so... this should be OK," while a user that is trying to install some random game mods from someone's Google Drive will have some pause for thought before going ahead and doing the unsafe. Obviously it's not a total panacea, but I think it's more effective than simple frustration.
I think Snap Store should manage Debian packages, though.
It's like Microsoft Windows didn't have an easy way to click and install .msi files. Maybe they don't use Microsoft Store to do it, I don't know, but the need to open a terminal and install using the command line can be cumbersome for many people.
I wouldn't say this about Arch, Gentoo, or even Debian, distros for more experimented users, but I will say that about Ubuntu since the niche is to be user-friendly, and not dealing with a simple, non-exoteric format like .deb packages is bad.
I won’t expect to Ubuntu to deal easily with Flatpak, since it was determined that is out of scope, but .deb still is fair game. If the applications are distributed in this .deb format, and they are, it should be an easy, clicky, way to install. Maybe another application to handle, not necessarily Snap Store itself, but some way to do things easy. Like how people can install Steam from steampowered.com since it's a .deb package and Steam is significant for users? Just an example, though, but consider Snap Steam is unrecommended right now by the developer itself, so there is a long way to replace .deb packages with Snap.
I think Snap Store should manage Debian packages, though.
It's like Microsoft Windows didn't have an easy way to click and install .msi files. Maybe they don't use Microsoft Store to do it, I don't know, but the need to open a terminal and install using the command line can be cumbersome for many people.
I wouldn't say this about Arch, Gentoo, or even Debian, distros for more experimented users, but I will say that about Ubuntu since the niche is to be user-friendly, and not dealing with a simple, non-exoteric format like .deb packages is bad.
I won’t expect to Ubuntu to deal easily with Flatpak, since it was determined that is out of scope, but .deb still is fair game. If the applications are distributed in this .deb format, and they are, it should be an easy, clicky, way to install. Maybe another application to handle, not necessarily Snap Store itself, but some way to do things easy. Like how people can install Steam from steampowered.com since it's a .deb package and Steam is significant for users? Just an example, though, but consider Snap Steam is unrecommended right now by the developer itself, so there is a long way to replace .deb packages with Snap.
I'd like to add that Valve still only offers official steam support on Linux for the Ubuntu operating system through the .deb package. (At least when I contacted them with an issue with a game.) That combined with the fact that most people coming from windows will automatically try to double-click an installer, to run it. I have friends who are scared to death of the command line and I have to recommend them away from Ubuntu because they can't install steam or other reputable, but really niche programs like manuskript by double-clicking.
I think Snap Store should manage Debian packages, though.
It's like Microsoft Windows didn't have an easy way to click and install .msi files. Maybe they don't use Microsoft Store to do it, I don't know, but the need to open a terminal and install using the command line can be cumbersome for many people.
I wouldn't say this about Arch, Gentoo, or even Debian, distros for more experimented users, but I will say that about Ubuntu since the niche is to be user-friendly, and not dealing with a simple, non-exoteric format like .deb packages is bad.
I won’t expect to Ubuntu to deal easily with Flatpak, since it was determined that is out of scope, but .deb still is fair game. If the applications are distributed in this .deb format, and they are, it should be an easy, clicky, way to install. Maybe another application to handle, not necessarily Snap Store itself, but some way to do things easy. Like how people can install Steam from steampowered.com since it's a .deb package and Steam is significant for users? Just an example, though, but consider Snap Steam is unrecommended right now by the developer itself, so there is a long way to replace .deb packages with Snap.
Android does it like this a warning appears on the entire screen that it is not safe in red and you have to wait 10 seconds to click I agree and am ready to accept the risk to install apk. Need just when he opens the deb file, the text will open why the deb version is not safe and he will be ready to accept the risks. And there will be large pictures in red with a warning, he accepts the offer and installation proceeds, but please, no timer
Hi, I think this may well be out of scope for the app center, but it should be a feature that exists in the default Ubuntu installation, similarly to proprietary drivers. A lot of official packages of software are in deb files without a repo, or a deb file that adds a repo (e.g. Google Chrome for the latter), and this adds a lot of friction to use Ubuntu, and to get support for various 3rd party software, especially when it's repackaged by Canonical. Regarding the security issues, this would've been more accepted had the snap store not had malware incidents 3 times in the last year or so. Sure, warn the user, make it crystal clear this is risky if the source is not trusted, but the option should stay, especially if the alternative you're suggesting here is to install something like gdebi, or use the command line, which does not warn at all.
Hi, I think this may well be out of scope for the app center, but it should be a feature that exists in the default Ubuntu installation, similarly to proprietary drivers.
A lot of official packages of software are in deb files without a repo, or a deb file that adds a repo (e.g. Google Chrome for the latter), and this adds a lot of friction to use Ubuntu, and to get support for various 3rd party software, especially when it's repackaged by Canonical.
Regarding the security issues, this would've been more accepted had the snap store not had malware incidents 3 times in the last year or so.
Sure, warn the user, make it crystal clear this is risky if the source is not trusted, but the option should stay, especially if the alternative you're suggesting here is to install something like gdebi, or use the command line, which does not warn at all.
To be fair the snap malware isn't their fault. However, it still makes canonical look less interested in security and more interested in I phone "security" if you know what I mean and that is not something that any Linux system wants.
People have suggested using a different app to install the files, I don't think so, because if the whole point with this operating system is to manage your apps well .debs are part of that and it should probably be all in the same place.
Unfortunately we didn't have the capacity to work on this for 24.04, but it will be a priority for the next cycle!
This should be a priority for 24.04.01.
I think since the Snap Store is, in fact, a Snap, makes things easier to upgrade.