"Glenn K0LNY" glennervin@cableone.net writes:
Finally, someone who understood my question. So the answer might be that the inability to keep up with dependencies would keep it from the distro's main repository? This is sort of what I was guessing, but wanted to make sure.
As a meta point, and coming from someone who works on packaging, you are more or less asking the question in the wrong forum.
chirp publishes releases (well, they are sort of labeled snapshots, and don't have normal version numbers, but it amounts to the same thing).
Packaging systems, which includes things other than Linux, as well as what the GNU/Linux world calls distributions, then either do or don't include any particular release, and do or don't keep it up to date.
There is a tendency these days for people to ask of an upstream (e.g. chirp) why their favorite Distribution X doesn't have the package, or why it's out of date. (There is an underlying notion that packages like chirp have a responsibility to ensure that Distribution X, for about a hundred values of X, have packaged chirp.) The answer is that these decsions are made by Distribution X people, not the maintainers of chirp.
This question -- why is chirp not in Distribution X -- should therefore be put to the Distribution X people, not to the chirp maintainers.
All that said, there is a large-scale issue these days with python 2, and other EOL software, where things that depend on it get kicked out of distributions. So when asking various Xs about why not chirp, you might well get the answer that it depends on things that are EOL and have been kicked out.
A packaging system has to balance something like python 2.7 being technically EOL (no more security fixes, since roughly April) and being so old and unmaintained that no sane user would use it. The real question is if dropping it from the distribution is truly a benefit to users. This is an issue where reasonable people differ, but I have seen some that want to remove it the day it comes out of support to force people not to use it (because stopping using it is good for the users, even if disruptive). I have seen some that call their distributions "LTS" and keep old software for a vastly long time beyond the last upstream maintenance -- and then demand that new releases build with their old versions.
The right approach is probably someplace in the middle, with python 2.7 being removed in late 2021 or maybe 2022, by which time probably only packages that are truly unmaintained will still be using it.
73 de n1dam