Re: Adam Bartlett 2019-05-10 <cadvnrhwzwp_oofsucelof0pydwxipiw_i+y0i1bi2juuanu...@mail.gmail.com> > One of the challenges of automatic updating is package managers and such on > the Linux side are often generations behind (not a big deal, but if a user > installs Ubuntu, types "apt install wsjtx" and they still have 1.x in their > repo it's going to confuse them) and trying to deal with those can be less > than fun. As someone who's had to support a lot of users over the years > (and has been a professional release engineer), automated updates can be > difficult to get right and very easy to get wrong (proper cryptographic > signing of packages, controls to ensure malware or unapproved features do > not escape into a release, etc).
Also, updating a piece of software that came over some channel over a different channel will likely be annoying. So no automated downloads or whatever please. (Says the Debian maintainer.) > My opinion is that the occasional nag screen would be useful - call home to > Princeton (or SF/Github/etc), if there's a update listed in a XML file it Fwiw, it's part of the Debian policies that packages shouldn't call home without the user's consent (you can probably also derive that from the GDPR). Maybe that's less strict with hamradio software that is meant to be used publically, but still. I guess the biggest problem here is that we can't tell when a certain version should expire. 1.9.x is clearly dead, but 2.0.x will possibly work forever unless the protocol changes again... Not trying to fix that problem might actually be the smartest solution. Christoph DF7CB _______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
