What's the best channel for requesting a package be updated? I've been advised on these forums to stick to the distro's repositories unless needed software isn't available there, but my earliest experiences with the repository were that the software was out of date there. Now, there can be good reasons for this: Zorin not being built with the libraries needed, stability issues with latest versions, etc., but sometimes old is just old.
The example that's most extreme (of which I'm aware) is Calibre, a suite of tools for ebooks. It's fantastic, very actively developed, and two years out of date in the repository. Calibre's download page explicitly advises people not to use the versions offered by distributions because they're often out of date and buggy, and there have been security fixes in the since the release of the version available in the repo. The maintainer appears to be "Ubuntu developers," and my searching implies that many times Ubuntu will only update packages when they release an update of Ubuntu itself (which, if true, means that sticking to one's distribution repos is a great way to have software missing features and patches). Calibre is two years out of date in the repo though, so that alone isn't it.
What's the best way to get something this horribly out of date updated? As long as this is what new users experience, they ARE going to learn to just go to a website and get their software there instead.
I would say that should go through the Ubuntu developers (as that's what Zorin OS uses as its base), perhaps on their forums they can point to a more exact contact or specific channel.
To get a more up to date package, you can install the Flatpak version which tend to be updated on par with newer releases. Downloading the binary from the project's website is also an option, though one that is not always guaranteed to work with a older version of Ubuntu if certain core dependencies are not up their required versions.
That's the choice you have to make: stability or frequent updates. Packages formats like Flatpak, Snap or AppImage are good choices to address this problem (though they come with their own baggage).
You can also use another distribution of Linux that focuses on just that, like Fedora or OpenSUSE Tumbleweed, that are continuously being updated and have the latest versions of software available soon after they are released.
This doesn't happen all that often, as most people don't actually need every single feature that a software has to offer all of the time, even though they might think they're missing out — FOMO is a real issue. For the occasional package, going with this approach is perfectly acceptable.
When one exists. Calibre does have a flatpak, but from an unverified source. One of the things I've been most uncomfortable about in using Linux software is the prevalence of software packaged by third parties. I'm sure it's almost all safe or at least well intentioned, but... well, one of my past jobs required lab samples have a detailed chain of custody. The more hands something passes through, the more opportunities there are for mischief.
Is that true of third party software as well? I'll be honest; I've got next to no familiarity with the goings-on of distributions' official repositories. It does not automatically follow (to my limited insight) that a distribution focused on being on the latest system components will also maintain packages for random, third party software with the same vigor. Nvidia drivers? Sure. (Though IIRC they were a pain to install on Tumbleweed.) One off e-book suites? Maybe? If they have a general practice of reviewing packages frequently, sure, but that's the part I'm not sure is necessarily true. (I'm not saying it isn't either; I'm asking and have no idea.)
Like many users here, I won't touch Snaps, but I don't share others' aversion to Flatpak or AppImage... except when, as above, the package isn't confirmed to be the software's developer.
The version of LibreOffice that came with Zorin 17.1 originally was actually confusing to me because its save icon didn't even look like the standard diskette almost universally used for the purpose. That's what actually started me down the path of mistrusting software provided by a distribution; Calibre being more than two years out of date accelerated it. This all came back to mind due to another post here from someone getting Piper working after the API it wanted (not sure which; I don't use Piper) was too old.
I'll look in that direction, thanks. I'd been hoping there was a known "report an old package" link I'd failed to find. Despite my fairly frequent presence here, I avoid public forums. This is the first I've made ANY use of since the late aughts, I think. The community here is to thank for that.
I never looked into this process myself but I found this page that talks about the process overall. It doesn't look like there's a request contact, but rather a process whereby people can directly submit contributions to be reviewed.
But I would definitely ask in the Ubuntu forums directly.
This is why digital signatures exist and why verifying the integrity of downloaded packages is important. But unless you are prepared to download and compile everything from source, you have to trust someone at some point.
Compiling from source has the advantage that you can use a package version that otherwise wouldn't be available in your distribution, as is the case here.
Personally, I don't trust the Flathub review process which is why I don't use any unverified Flatpaks, and why I think Linux Mint's decision from hiding results from unverified Flatpaks is spot on.
On the other hand, I do trust Canonical's process, so I don't mind using software where the developers are not the same as the maintainers.
Note that I can still go out of my way at any point to verify if something is legitimate or not. It's just a more work.
There are also cases where using newer software has resulted in catastrophic failures. Newer does not mean better, nor worse... it just means newer.
What I'm saying is simply that something that has proven to work reliably shouldn't be considered bad, inadequate or anything of the sort. Not without proof, anyway.
For this reason, I would only direct people to download something outside of the official repositories when there's value from doing so. But otherwise, I don't think something being horribly out of date is actually that horrible.
That is precisely the difference between the Long Term Support and rolling release models.
I'm not familiar with the intricacies of how each distribution does their own review process, but even with automated testing processes and so on, it's simply not possible to test everything so thoroughly in so little time. It's a balancing act between stability and novelty.
Digital signatures are a solution to the wrong problem. They ensure that the file you receive is the file the source intends to provide. I was talking about third parties packaging a developer's software, as in community maintained flatpaks and the like. If a malicious third party creates the package, they're also going to provide the signature. The original author's signatures won't mean much, since they didn't create the package. For individually signed files IN a package, they could be verified, but I don't think I've ever seen a list of hashes provided for the contents of a package.
When the developer creates the package, I have to trust one person (or group, or whatever). When a third party packages something as a service to the community, I have to trust the original author and and the packager. If it's a fork, I have to trust the original author, whoever worked on the fork, and the packager. So on and so forth. So, to maintain my sanity, packages provided by third parties are just not something I'm willing to trust.
(Also, even if I'm compiling from source, I still have to trust someone. The open source security benefit of being able to see the code is great, but the ability of any given person to leverage it him or herself extends as far as their coding ability and familiarity with what the application's doing. That is to say, I benefit from OTHERS having access to source, but self-compiling or binaries from the developer are exactly equal in trustworthiness, as I can glean nothing from either.)
I would revise that to "newer does not inherently mean better or worse." For any given software project, newer usually means one or the other. In the case of the Calibre example though, we're talking two years, two major releases (6.x and 7.x) and several dozen point releases. As I originally mentioned, some of Calibre's fixes have been security related. Some are performance related. Newer has been better for some significant number of updates there.
I understood that to be the case with the operating systems' components and presumably pre-installed software. I was not aware it extended to updating repositories for third party software, at least beyond cases where newer versions COULDN'T be adopted due to conflicts.
The Thing is: When You would implement a newer Version, You have to implement newer Versions of the Dependencies. And newer Versions for the Dependencies of the Dependencies. So, it isn't only bring a new Version of a Program. A Flatpak or an AppImage brings the Dependencies with it; that is the Reason why they can be relatively big.
If you are looking for a good Balance between Stability and a good up-to-date System, Fedora would be worth a Try I think. It isn't directly the cutting Edge but way more up-to-date than a LTS Distro.
Perhaps I should be clear about one other point: this isn't about moving Zorin or Ubuntu along faster. Calibre is perfectly capable of running from its install script on its website. Zorin has everything it needs to run the most up to date Calibre. This isn't about changing distributions. Zenzen's remark implied to me that a distribution that kept its components newer would also update external, third party packages more often, which is not an assumption I would have made.
I'm also not talking about mildly out of date software. The version in the repository is slightly older than Zorin 16.1.
(If you install Calibre from the site's provided command line, it will lack one dependency when run, but it tells you which, and a single apt install will get the job done.)
I mean, the main reason for updating core system libraries is to enjoy newer features that have been added (beyond the obvious security related reasons). Software developers will use those features eventually, so it makes little sense to being able to support new features but not actually use them. It's like expanding the highway while not using the new lanes.
On the other hand, updating one library often requires doing the same for others, as a result of the dependency cascade. This push for newer features naturally leads to a situation where there's basically no middle ground: either draw the line at a specific version and eventually become "outdated", or keep pushing updates continuously.
You are correct in that you need to know what is the correct frame of reference. Digital signatures cannot protect you from mischief, just like encryption cannot protect you from someone looking over your shoulder as you type in you master password.
This is why source code is used as the source of truth. The fact that trust is involved when you use any repository is another story; it's practically unavoidable, yes, but a different story nonetheless. This is why I said in my previous post that you can always go straight to the source code, compile it and compare the signatures.
That, arguably, is the best thing about open source. Even if you were Linus Torvalds himself, there's only so much you can do with your time, especially in such an incredibly fast moving industry. Every successful business needs to delegate work to others at some point.
From what I've found, it looks like the page I linked is the correct place to make a request to update some package. Although I'm still not quite sure how that request would look like, it's not very well documented despite it being the documentation
Another option would be to use the backports repository but I personally don't like the idea. Here you can see what I mean about dependencies:
