Bug#950926: ember: Using packages to install "snap" packages is not a correct use of the packaging system
User: tobi-rm-proposals@d.o Usertags: rm-proposal (FTR, I also don't think that snap/flatpak/appimage should be pulled by an Debian package) I agree with Olek, Ember (and friends) were always hard to keep floating in Debian, so I can understand Oleks' sentiment about maybe using snap… However this can be done by the users themselves, there is no need to have a debian package doing so. So, maybe, it is time to let ember go and remove it from Debian? It has no reverse dependencies, so it is save to do so. I'll reassign this bug to ftp.debian.org in 3 months, if there is no veto in this bug. -- tobi (Doing bug triaging on games team packages) signature.asc Description: PGP signature
Bug#950926: ember: Using packages to install "snap" packages is not a correct use of the packaging system
Control: tag -1 = confirmed Thanks for reminding me about this bug, tobi! I guess a lot has been happening since February of 2020 On 8/27/22 08:11, Tobias Frost wrote: > User: tobi-rm-proposals@d.o > Usertags: rm-proposal > > (FTR, I also don't think that snap/flatpak/appimage should be pulled by an > Debian package) So I did think about what Manuel said although life and world events distracted me from replying. I am now of the opinion that although I had the best of intentions and (at the time) logical reasons for doing so, packaging a Snap is an inherently bad and problematic concept. So, I agree with you. :) > I agree with Olek, Ember (and friends) were always hard to keep floating in > Debian, so I can > understand Oleks' sentiment about maybe using snap… However this can be done > by the > users themselves, there is no need to have a debian package doing so. Yes... But I got S much great packaging experience from that! ;) In all seriousness: yes, I agree, a user can install a Snap and it's a waste of time for package maintainers to do so. > So, maybe, it is time to let ember go and remove it from Debian? I'd really hate to see that happen but if the code isn't in a stable state soon then I'm not sure there will be much of a choice. I've reached out to upstream to inquire about the timeline. Depending on that response, I'll decide how to move forward. The Ember client hasn't seen a release since November 2019 and the Cyphesis server hasn't been released since October 2013. A lot has changed since then and neither of those releases is maintainable at this point. Either way, I've marked this bug confirmed because I now fundamentally agree with the issue. > It has no reverse dependencies, so it is save to do so. > > I'll reassign this bug to ftp.debian.org in 3 months, if there is no veto > in this bug. Let's try to figure this out sooner. :) -Olek OpenPGP_signature Description: OpenPGP digital signature
Bug#950926: ember: Using packages to install "snap" packages is not a correct use of the packaging system
As the main developer of Worldforge I'm perfectly fine with it being provided as Snap instead of being part of the Debian base packages. The way development happens makes it not well suited for Debians focus on stability. We often need to make changes to the protocol that has changes to the client and server happening in sync. The Snap allows us to move more quickly, which suits this specific project. sincerely Erik Ogenvik Den lör 10 sep. 2022 kl 02:39 skrev Olek Wojnar : > Control: tag -1 = confirmed > > Thanks for reminding me about this bug, tobi! I guess a lot has been > happening since February of 2020 > > > On 8/27/22 08:11, Tobias Frost wrote: > > User: tobi-rm-proposals@d.o > > Usertags: rm-proposal > > > > (FTR, I also don't think that snap/flatpak/appimage should be pulled by > an Debian package) > > So I did think about what Manuel said although life and world events > distracted me from replying. I am now of the opinion that although I had > the best of intentions and (at the time) logical reasons for doing so, > packaging a Snap is an inherently bad and problematic concept. So, I > agree with you. :) > > > I agree with Olek, Ember (and friends) were always hard to keep floating > in Debian, so I can > > understand Oleks' sentiment about maybe using snap… However this can be > done by the > > users themselves, there is no need to have a debian package doing so. > > Yes... But I got S much great packaging experience from that! ;) In > all seriousness: yes, I agree, a user can install a Snap and it's a > waste of time for package maintainers to do so. > > > So, maybe, it is time to let ember go and remove it from Debian? > > I'd really hate to see that happen but if the code isn't in a stable > state soon then I'm not sure there will be much of a choice. I've > reached out to upstream to inquire about the timeline. Depending on that > response, I'll decide how to move forward. The Ember client hasn't seen > a release since November 2019 and the Cyphesis server hasn't been > released since October 2013. A lot has changed since then and neither of > those releases is maintainable at this point. > > Either way, I've marked this bug confirmed because I now fundamentally > agree with the issue. > > > It has no reverse dependencies, so it is save to do so. > > > > I'll reassign this bug to ftp.debian.org in 3 months, if there is no > veto > > in this bug. > > Let's try to figure this out sooner. :) > > -Olek >
Bug#950926: ember: Using packages to install "snap" packages is not a correct use of the packaging system
Package: ember Version: 0.8.0~snap1 Severity: serious Hello, I don't think taht using this package as an empty shell and a gateway to install the "snap" package [1] is a valid use of the packaging system. Otherwise, if this was an accepted practice, we could start to have many packages which are just a way to install snap packages, which can easily contain security vulnerabilities and install not free software, specially if the version is not restricted in some way. And this not generally expected by users of Debian, IMO. If users want to install Snap packages, they can always do so on their own. So please reconsider and either package the game properly or drop this package altogether. [1] https://salsa.debian.org/games-team/ember/blob/master/debian/ember.preinst Cheers. -- Manuel A. Fernandez Montecelo
Bug#950926: ember: Using packages to install "snap" packages is not a correct use of the packaging system
Hi Manuel, Thanks for your bug report and thanks for your thoughts. However, at this point I'm inclined to respectfully disagree with you on this subject. On 2/8/20 8:44 AM, Manuel A. Fernandez Montecelo wrote: > Package: ember > Version: 0.8.0~snap1 > Severity: serious > > Hello, > > I don't think taht using this package as an empty shell and a gateway to > install > the "snap" package [1] is a valid use of the packaging system. Not only is this use listed in Policy [1] under the contrib section (where I'm moving the two packages I've done this with, pending NEW) but a number of other packages (in contrib) do exactly the same thing. Flash [2] being the obvious example. I'd also like to point out that I asked about this course of action back in December [3] and no one raised any concerns. So it's a little frustrating that after I've done all the work to convert the packages I'm now getting feedback saying I shouldn't have done it. > Otherwise, if this was an accepted practice, we could start to have many > packages which are just a way to install snap packages, which can easily > contain > security vulnerabilities and install not free software, specially if the > version > is not restricted in some way. And this not generally expected by users of > Debian, IMO. This is a fair concern. However, I think that users *do* expect this of packages in contrib. Pabs made a good argument in a different bug report about this issue and convinced me. I'm going with that. However, I do agree that this shouldn't be *normal*. Ideally, we should host source code and build the packages ourselves, in main. In this case, I see this as a gap-filler while the upstream packages go through a period of extreme instability. Upstream is very small and this process is likely to last more than a year. I structured the transitional packages, and annotated a comment in d/copyright, explaining that this is a temporary step to have a usable package (for Debian users who opt in to contrib) until upstream stabilizes and I can package it in main again. > If users want to install Snap packages, they can always do so on their own. They can. I'm just trying to provide a transition path that will eventually lead to the main packaging of the updated upstream software. > So please reconsider and either package the game properly or drop this package > altogether. FWIW, I am planning to temporarily drop the supporting Worldforge libraries [1] since they will just be taking up space in the archive and they'll get pulled back in to a user's system once Ember and Cyphesis return to main. Again, I want to clarify that I am open to inputs (and I appreciate yours) and I'm happy to continue the discussion if you have additional points that you think I should consider. But I really wish that these concerns had been brought up back in December... > [1] https://salsa.debian.org/games-team/ember/blob/master/debian/ember.preinst -Olek [1] https://www.debian.org/doc/debian-policy/ch-archive.html#the-contrib-archive-area [2] https://packages.debian.org/sid/flashplugin-nonfree [3] https://lists.debian.org/debian-devel-games/2019/12/msg0.html signature.asc Description: OpenPGP digital signature
Bug#950926: ember: Using packages to install "snap" packages is not a correct use of the packaging system
Hello Olek, Em sáb., 8 de fev. de 2020 às 18:25, Olek Wojnar escreveu: > > I don't think taht using this package as an empty shell and a gateway to > > install > > the "snap" package [1] is a valid use of the packaging system. > > Not only is this use listed in Policy [1] under the contrib section > (where I'm moving the two packages I've done this with, pending NEW) but > a number of other packages (in contrib) do exactly the same thing. Flash > [2] being the obvious example. I'd also like to point out that I asked > about this course of action back in December [3] and no one raised any > concerns. So it's a little frustrating that after I've done all the work > to convert the packages I'm now getting feedback saying I shouldn't have > done it. I am sorry that you made the work and noone told you about this. Maybe I am in the minority and most people don't see it this way, don't know. I simply stumbled upon the package by chance, and I didn't have time to follow mailing lists regularly in the last months, and I think that I haven't read debian-games for years. But to the point about the installation of snaps and "flash", as far as I see it, there are two fundamental differences: 1) For flash, and I guess that most packages of contrib, the items that are download are checksummed [1], so we know what the script installs, and we have to manually approve new versions. If the download is known to be compromised, users will not install new versions (and we can do removal of existing versions in some cases, if we only find that it's a security problem after users install it, at least in some cases). [1]https://sources.debian.org/src/flashplugin-nonfree/1:3.7/update-flashplugin-nonfree/ This does not happen with the installation of these snaps, as far as I can see -- it will take whatever is there, the latest version, no checksumming or pinning to known-good versions, and there's no guarantee that if tomorrow someone takes over that package and installs malware, that users installing it from Debian will not use it. Once users install the snaps, it's completely outside of Debian's control, I think. 2) These kind of methods are done for special packages like firmware, very popular apps like flash (at the time), etc, or *data* packages from games. It's a "known evil" thing to do, still we do it because it's somewhat needed by many users -- nowadays you can easily live without flash, but it was not so easy in the web 10 years ago; it's impossible to install some computers without firmware, etc. But I don't see the need to do it with a very marginal package like Ember. Either people are happy to run the older version from 2016, or if not, they would have already updated it by some means, like maybe using themselves the snap package. So I don't think that it's worth promoting things that are a bit against the philosophy of Debian/traditional distros, like snaps (adding layers of overhead and duplication, and potentially security vulnerabilities) due to a package with very low popcon and which use is not critical, it's just a game. 3) Aside from that, I would be more OK with it if, before installing, there were clear indications of what's going on for people that might be unaware of what Snaps are, and that fail to notice the change in description of the package. As I understand it, there's no indication that you'll install a snap package if you just do "apt-get upgrade". That's the part that I think it's more troubling, that you can end up installing snap packages without even noticing -- maybe because you happened to have "ember" installed in the past and you wanted to check it up one time long ago, and are not even using it very actively in the last months/years. If you have something like a debconf question asking users if they want to install the snap package, or invoke snap and you decide if you want to install it or not without the configuration of the package failing if you reject, etc, then I think that it's much more reasonable. > > Otherwise, if this was an accepted practice, we could start to have many > > packages which are just a way to install snap packages, which can easily > > contain > > security vulnerabilities and install not free software, specially if the > > version > > is not restricted in some way. And this not generally expected by users of > > Debian, IMO. > > This is a fair concern. However, I think that users *do* expect this of > packages in contrib. Pabs made a good argument in a different bug report > about this issue and convinced me. I'm going with that. This and cyphesis are the only packages that depend on snapd, which are not app-managers from GNOME/KDE and the like, so I don't think that users expect it? These are among the first cases that we do something like this, unless we do it also with flatpaks or similar and I failed to notice (which can easily happen, I have not been very active lately on many fronts). For games, most of the cases that I kno
Bug#950926: ember: Using packages to install "snap" packages is not a correct use of the packaging system
Hmm.. some good points to ponder. Thanks! Let me think on that a little and I'll respond more fully. -Olek On 2/9/20 5:12 PM, Manuel A. Fernandez Montecelo wrote: > Hello Olek, > > Em sáb., 8 de fev. de 2020 às 18:25, Olek Wojnar escreveu: >>> I don't think taht using this package as an empty shell and a gateway to >>> install >>> the "snap" package [1] is a valid use of the packaging system. >> Not only is this use listed in Policy [1] under the contrib section >> (where I'm moving the two packages I've done this with, pending NEW) but >> a number of other packages (in contrib) do exactly the same thing. Flash >> [2] being the obvious example. I'd also like to point out that I asked >> about this course of action back in December [3] and no one raised any >> concerns. So it's a little frustrating that after I've done all the work >> to convert the packages I'm now getting feedback saying I shouldn't have >> done it. > I am sorry that you made the work and noone told you about this. > Maybe I am in the minority and most people don't see it this way, > don't know. > > I simply stumbled upon the package by chance, and I didn't have time > to follow mailing lists regularly in the last months, and I think that > I haven't read debian-games for years. > > > But to the point about the installation of snaps and "flash", as far > as I see it, there are two fundamental differences: > > 1) For flash, and I guess that most packages of contrib, the items > that are download are checksummed [1], so we know what the script > installs, and we have to manually approve new versions. If the > download is known to be compromised, users will not install new > versions (and we can do removal of existing versions in some cases, if > we only find that it's a security problem after users install it, at > least in some cases). > > > [1]https://sources.debian.org/src/flashplugin-nonfree/1:3.7/update-flashplugin-nonfree/ > > This does not happen with the installation of these snaps, as far as I > can see -- it will take whatever is there, the latest version, no > checksumming or pinning to known-good versions, and there's no > guarantee that if tomorrow someone takes over that package and > installs malware, that users installing it from Debian will not use > it. Once users install the snaps, it's completely outside of Debian's > control, I think. > > > 2) These kind of methods are done for special packages like firmware, > very popular apps like flash (at the time), etc, or *data* packages > from games. It's a "known evil" thing to do, still we do it because > it's somewhat needed by many users -- nowadays you can easily live > without flash, but it was not so easy in the web 10 years ago; it's > impossible to install some computers without firmware, etc. > > But I don't see the need to do it with a very marginal package like > Ember. Either people are happy to run the older version from 2016, or > if not, they would have already updated it by some means, like maybe > using themselves the snap package. > > So I don't think that it's worth promoting things that are a bit > against the philosophy of Debian/traditional distros, like snaps > (adding layers of overhead and duplication, and potentially security > vulnerabilities) due to a package with very low popcon and which use > is not critical, it's just a game. > > > 3) Aside from that, I would be more OK with it if, before installing, > there were clear indications of what's going on for people that might > be unaware of what Snaps are, and that fail to notice the change in > description of the package. > > As I understand it, there's no indication that you'll install a snap > package if you just do "apt-get upgrade". That's the part that I > think it's more troubling, that you can end up installing snap > packages without even noticing -- maybe because you happened to have > "ember" installed in the past and you wanted to check it up one time > long ago, and are not even using it very actively in the last > months/years. > > If you have something like a debconf question asking users if they > want to install the snap package, or invoke snap and you decide if you > want to install it or not without the configuration of the package > failing if you reject, etc, then I think that it's much more > reasonable. > > >>> Otherwise, if this was an accepted practice, we could start to have many >>> packages which are just a way to install snap packages, which can easily >>> contain >>> security vulnerabilities and install not free software, specially if the >>> version >>> is not restricted in some way. And this not generally expected by users of >>> Debian, IMO. >> This is a fair concern. However, I think that users *do* expect this of >> packages in contrib. Pabs made a good argument in a different bug report >> about this issue and convinced me. I'm going with that. > This and cyphesis are the only packages that depend on snapd, which > are not app-managers from GNOME/KDE
Bug#950926: ember: Using packages to install "snap" packages is not a correct use of the packaging system
On Sun, Feb 09, 2020 at 11:12:48PM +0100, Manuel A. Fernandez Montecelo wrote: 2) These kind of methods are done for special packages like firmware, very popular apps like flash (at the time), etc, or *data* packages from games. We have game-data-packager (gdp, which I originally wrote) for situations like this. When you generate a .deb (as gdb does) containing the data and install that, you get an Installed-Size which reflects the actual disk usage of the package; you know that data is removed again when you remove the package; you can express package inter-dependencies properly, etc. The ember package, at present • claims to have an Installed-Size of 35.8 kB but will install 177+MiB in pre-inst • Does not clean that up again on package removal • Doesn't handle "snap install" failing, silently completes package installation • Supplies a .desktop file referencing Exec=ember but does not provide any ember binary (even as a route into the snap) in $PATH It would be interesting to see whether game-data-packager could consume data from snaps, and avoid all these pitfalls. I believe smcv was interested in something similar for flatpaks (that might have been installing into flatpaks, rather than consuming from them) -- 👱🏻 Jonathan Dowland 🔗 https://jmtd.net
Bug#950926: ember: Using packages to install "snap" packages is not a correct use of the packaging system
On Tue, 25 Feb 2020 at 15:02:21 +, Jonathan Dowland wrote: > It would be interesting to see whether game-data-packager could consume > data from snaps, and avoid all these pitfalls. That would remove the sandboxing and known-runtime-libraries properties of the snap packaging system. I wouldn't recommend that. The apt/dpkg packaging system is set up for a single, system-wide dependency tree. That's great for binaries that were built within the scope of that dependency tree, but unsuitable for binaries that were built with different assumptions (unless the binaries were deliberately built to have minimal dependencies, like the few proprietary binary-only games supported by game-data-packager, or with no assumptions at all, like the data for Free game engines that is the majority of what game-data-packager deals with). If what you want is to install Snap packages, then I would suggest installing Snap packages (perhaps through something like GNOME Software, which knows about multiple ways to install software). Not every piece of software has to be delivered as a .deb. If ember is no longer feasible to package as a .deb in Debian, then only releasing new versions of it as Snap packages (or Flatpak or AppImage or whatever) is perfectly reasonable; but in that case, I don't think a .deb package that installs those other-packaging-system packages from third-party repositories is a great upgrade path. > I believe smcv was > interested in something similar for flatpaks (that might have been > installing into flatpaks, rather than consuming from them) Off-topic for Ember: Yes, this is the other way round. I wanted to be able to turn games (particularly proprietary games like Unreal 1) into Flatpak packages as an alternative to .deb (and .rpm and Arch Linux packages, which should now mostly work too). Some of the same reasoning would apply equally to turning those games into Snap packages, although I think Flatpak is a better fit, so I don't plan to work on that myself. Why I wanted to do that: - Flatpak apps are, or can be configured to be, sandboxed (placed in a limited container without access to, for example, ~/.ssh). Snap has the same idea, although the details are different (Flatpak is likely to be a lot better-confined on systems that don't have Ubuntu's non-upstream kernel patches for better AppArmor). - Flatpak apps run on a set of libraries that don't have to match the ones on the host system, so we can run proprietary games from the distant past in (for example) a Debian-10-based container that has SDL 1, GTK 2, etc. without having to keep those libraries in the development branch of Debian forever. I think Snap can do the same thing, but the details of how it achieves it are rather different. - Flatpak apps can be installed "for just me" (in ~/.local/share) unprivileged, or system-wide (into /var/lib) with appropriate privileges. I don't think Snap apps can be installed per-user without exercising privileges. - Identical files in Flatpak apps are automatically deduplicated by content (this is relevant if you have overlapping games installed, like Unreal, Unreal Gold and Unreal Tournament). I don't think Snap does this. smcv
Processed: Re: Bug#950926: ember: Using packages to install "snap" packages is not a correct use of the packaging system
Processing control commands: > tag -1 = confirmed Bug #950926 [ember] ember: Using packages to install "snap" packages is not a correct use of the packaging system Added tag(s) confirmed; removed tag(s) moreinfo. -- 950926: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950926 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
