Seems like the best way then would be if they maintain their own channel, as is the case with CHIRP, VirtualBox, and countless other applications. Then I could add that source and the package manager would use the more up to date packages seamlessly. The packages are already being built for a number of different platforms in the proper package formats, tossing them in a proper repository for each wouldn’t be a significant increase in effort.
Side-note, I also encountered a problem where version 2.X seems to not be compiled against the correct glibc versions for Ubuntu 16.04-LTS base, which may be related to why its not updated in the Ubuntu channel if they are just picking up what is already built. I have been having to recompile it myself with 2.0 and 2.0.1 as well as the 2.1RC5. FWIW I had no idea about any update until a local ham told me about needing to update with 2.0 when I mentioned it one morning. The other idea would be as someone else suggested, put a "header" or something with a version that goes out over the air...now you won't have to make the software "phone home", it can simply decide the version the other people are sending and if its newer than what it has, tell the user "Hey, it looks like there is a newer protocol version, you should go <website> to check for updates!" That would be a cross-platform solution without needing to worry about package managers or "phoning home" or Internet access at all. Maybe that would be the best way? -Matt / KK4NDE -----Original Message----- From: Christoph Berg [mailto:[email protected]] Sent: Friday, May 10, 2019 12:21 PM To: WSJT software development Subject: Re: [wsjt-devel] Expiration Date on Software 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 _______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
