Hello Olek, Em sáb., 8 de fev. de 2020 às 18:25, Olek Wojnar <o...@debian.org> 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 know of in which we have games in contrib is because of free game engines or "clones" that need non-free data from the original games or similar, not "snaps" or flatpaks or similar. (I have the impression that pabs misunderstood the intention and was talking about upstream providing alternatives to snap, not Debian, but let's not enter that territory.) > > 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. What I am concerned about is that you're susbtituting a normal package for a snap package and people might acquire it by upgrading it without any notice, that's why I am raising the flag. So, as I see it, while you provide a convenience to those who are OK with it, you're providing a semi-hidden *inconvenience* to people who don't want it to happen. I know that your intention is to help those who want to keep Ember installed and are OK with a snap package, but I wanted to raise the flag and protect users from installing stuff without intending it and without much of a notice. At least, I would be surprised if that would happen to me, that's why I am raising it. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>