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 <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>
signature.asc
Description: OpenPGP digital signature