[chirp_users] Why Isn't Chirp In The Main Repository Of LinuxDistros?
gdt at lexort.com
Thu Oct 8 18:00:14 PDT 2020
"Glenn K0LNY" <glennervin at 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
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
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 194 bytes
Desc: not available
Url : http://intrepid.danplanet.com/pipermail/chirp_users/attachments/20201008/c0e718f0/attachment-0002.bin
More information about the chirp_users