[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: [PATCH] ham/chirp update
On Sat, 11 Jul 2020 at 14:53, Greg Troxel <gdt%lexort.com@localhost> wrote:
> Paul Ripke <stix%stix.id.au@localhost> writes:
> > Just been mucking with some radios and CHIRP, and noticed our pkgsrc
> > version is rather old. Attached patch bumps it to the latest
> > chirp-daily. Not sure if I got everything right, but I've managed
> > to program a couple of radios successfully.
> As a rule pkgsrc packages releases. I realize that some upstreams are
> broken in that they don't make releases even when they tell everyone not
> to use the release because it is too old. So we are not 100% on don't
> do that. But it would be nice to have an upstream bug about not having
> a release to point to. (This is just an example of the general
> principle in pkgsrc that upstream problems should be fixed upstream, and
> if we have workarounds, we should be clear and readers of the pkgsrc
> bits should be clear that what we have is a workaround for upstream
> I am in general much more comfortable having a 2nd package that is
> tracking the latest development branch, than updating the main one. But
> in this case that may be tilting at windmills.
> We often call these things -devel, to say what they are semantically, vs
> how we get them (daily snapshots, git, svn, etc.).
> Are you willing to add this to wip? It is much easier for me to deal
> with updates/new pacakges in wip, because it skips the
> unpacking/etc. step and multiple people can make tweaks.
> Info at
> and to get commit privs all you need to do is mail an ssh key as
> described in the link.
What you say makes sense in principle, but in the case of chirp,
upstream have decided they are going to release their packages as
chirp-daily. I think the OP's approach probably makes more sense.
"you do not need to worry about finding a stable version to run. You
should always be on the latest build available."
Main Index |
Thread Index |