https://bugs.documentfoundation.org/show_bug.cgi?id=164790
--- Comment #7 from Emiliano Vavassori <[email protected]> --- I appreciate your enthusiasm for the enhancement proposed, although I think you are missing some (non-trivial, non-detail) considerations: 1 - I am not a developer, not at all. As such, I do not have the needed knowledge to mingle with the 7+ MLOC in C++ of the LO project itself. That results in the fact that I am not able to change the default behavior of LO, or even alter only the AppImage behavior itself; 2 - I am a volunteer and my daily job has nothing to do with LO nor doesn't pay a penny for any development over AppImages and/or LibreOffice. As such, I might not have the time, the continuity or the energies to take up an effort more than replying to inquiry, ensuring my private CI/CD pipeline stays in shape and/or do some minor changes to the packaging script for AppImages; 3 - AFAIK, TDF's Engineering Steering Committee expressed itself multiple times in the past basically refusing/denying any kind of support related to AppImages, with very valid reasons to be fair: supporting this release format would be an additional workflow to the standard releasing process, basically with its own security, QA, documentation and releasing teams and with a small/non-existent market for it. As such, any work to the AppImages has been taken over and offered to the general public in a best-effort way by volunteers. I think it is the same for other release formats (snap, flatpack and even Chocolatey), but I didn't check thoroughly; 4 - At the moment, the built AppImages are only a repackaging of the official binary .deb packages from TDF; which finally means that I cannot change, alter, fix, twist and/or distort any of the behaviors, bugs and features of the released version; 5 - My pipeline (which runs on private volunteered infra enabled by private/volunteer fundings) needs to poll the official website to learn when a new release is available, then download every packages from the official archive, then build the required set of AppImages. An integration in the official pipeline has never been discussed nor explored, not by infra team and even more, not by the ESC. That results in the facts that the AppImage release following an official release will surely be delayed at worst by a little short of 2 hours (if my pipeline checked for a new version and a new release appears just a second after, it would take another full hour for the pipeline to poll again the website and another additional 20-40 minutes to rebuild all the AppImages needed). I am of course available to lend a hand and/or discuss for a better process, but what I am definitely not willing to do is to bring the AppImage effort to the ESC, only to be (rightfully and again) denied of any support, nor increment my involvement in terms of developing time or knowledge, even for the specific context of AppImages. That said, I think I can provide some objective answers to your questions. (In reply to CP from comment #0) > Description: > I periodically get a notification that a new version of LibreOffice is > available - as I did today. I'm running AppImage 24.2.7.2 at the moment, but > got the notification because 24.8.4 has now been released. This is an internal LO process, coded in C++ and, for sure, it doesn't check the availability of a new AppImage version, but only of an official release. I can see it would be technically possible to alter the behavior here, but I am not the right person to discuss it with nor I can decide myself on the matter. > But when I go to > download the "AppImage" file, there is no version information in the > download file That is deliberate - the download button stays the same throughout releases and points to the same exact URL, which is definitely a copy/symbolic link of the (matching and updated) versioned AppImage. The URL points to a file resource that exists on a web server and not to a script that needs to determine the last version for both branches (including requests for help pages, additional languages, signed packages and/or portable builds - you can now see the domain is quite expanded and complex). I bet using the loaih python package [1] I released on behalf of LibreItalia would help write such script, but I am not willing to invest even an hour more on this functionality. That said, on the very same page of the AppImage downloads you can find the link to the archive (https://appimages.libreitalia.org; check out the section "More Downloads"), which contains all versioned releases of LO in form of AppImage. Inside the archive you can also find: * For each file, an MD5 hash (in the form of an additional .md5 file) you can check to verify your downloads (or verify your unversioned AppImage is effectively the last versioned one); * A "branch" naming of the AppImage, additional to the still/fresh naming - Libreoffice-24.8.basic-x86_64.AppImage for example points to the latest patchlevel release for the 24.8 branch, actually 24.8.4.2; * The zsync files that allows you to update an existing LO AppImage to the latest version related to the specific zsync file - for example, if you run something like `zsync2 -i Libreoffice-still.standard-x86_64.AppImage https://appimages.libreitalia.org/LibreOffice-24.8.4.2.standard.help-x86_64.AppImage.zsync` you will update your AppImage to the 24.8.4.2 AppImage version with standard languages AND help pages, and additionally downloading only the "delta" parts (or a little more). zsync2 is sadly available only as AppImage releases on the related website [2]; my advice is to use the "Continuous build" prerelease (actually, version 75-9337846) as it is the only one that worked fine on my system. > "LibreOffice-still.standard-x86_64.AppImage" and the only way I can tell if > you have actually posted a new version of the AppImage is to download from > the link and then compare the new file with my existing one. With the information provided on the AppImage download page and following with blinders on only the download buttons, yes. There might be other approaches, though; you can check your AppImage version by running it, then going to "Help > Information on LibreOffice" - in the Version line you have the version of LO bundled in the AppImage. You can confront if that version is the same provided by the general download page, and if not you don't have the latest version (and you just downloaded the official downloads page in addition). Another approach would be to download the .md5 file in the AppImage Archive related to the latest version and confront it to the md5 hash of your file. > Can you PLEASE change the naming convention of your AppImage files to be > something like:- As @gponzo has explained, they are already available at the AppImage Archive repo. > I'm using a metered connection and I just wasted @ 340Mb of my monthly > allowance to download a version I'm already running. Please check again my explanation of zsync2 above, then; I'm sure you will appreciate it. > Additional Info: > This should not require any code changes, this should literally be nothing > more complex than renaming the AppImage file that is being offered for > download. In my perspective, the links provided by the official AppImage page, in form of buttons, are only a shortcut for the laziest/luckiest between us, that do not bother to check/update previously downloaded files and simply want to download a full version each time. For other use cases, a little bit of research is required; although I can admit moving most of the information I provided here in a wiki page and linking it to the official AppImage page would be a big step forward - I'm less sure that those information would be consulted frequently, thought. (In reply to CP from comment #6) > Specifically in the case of the AppImage download, what happpens [and it was > the case when I opened this ticket] is that I got a notification from my > local LibreOffice client to tell me that a new version was available... As said and explained, there is no way (at the moment, at least) that the AppImage releases are even considered when doing this check. > Is it possible for you to ensure that ALL of the supported file formats are > available at the same time? Not possible (at least at the moment), as the delivery pipeline for AppImage is separate from the official one and needs to poll the website to "discover" that a new build is needed. > Maybe there is a second part to this ticket, which is to look at your > publication process - and/or your "new version available" notification > process? Maybe there is a path here were the user of an AppImage file > actually doesn't get the notification *until the AppImage file version is > updated*? As said, this has nothing to do with the AppImage and I'm afraid noone of the developers, nor the ESC, would approve to review this process to fit in the AppImage releases (check item 3 at the top of my answer). > Of course I understand that some of the above suggestions are going to > require quite a lot of sophistication that needs to span your hosting and > your "update checking" code in running binaries... but I think all of this > should be possible. I agree it should be technically feasible, but again this is not a technical decision at all. > Of course, you don't need to do all of these things to solve the root > problem - I think that version-naming the download images and making those > versions visible at the point of download will go a long way to address my > original concern. But I also think there are some really cool additional > approaches you could take, if you are feeling a bit more adventurous. Pointing to a versioned AppImage name requires: a) updating the links on the AppImage page in the official website at every release (and waiting that an AppImage set for the new release to be built) or b) creating a script on the hosting side to provide the correct pointer to the fully versioned file. Both of these solutions requires an effort I am not available to provide; the actual situation is definitely more leaner than both of the solutions. And, since 2 years, you are the only one noticing it or needing something different than a link that just works. Not saying an adjustment is definitely superfluous, but still, I'd evaluate the actual impact on users of the proposal and its time/work counterpart to implement it. Hope this helps; I am of course available to deepen the analysis, if needed. [1]: https://pypi.org/project/loaih/, which source is hosted at https://git.libreitalia.org/libreitalia/loaih [2]: https://github.com/AppImageCommunity/zsync2 -- You are receiving this mail because: You are the assignee for the bug.
