Ahoy there! Matija Nalis wrote: > Debian contains old version 0.0.14 of obfs4proxy, new upstream is at 0.8.0 > https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird
It's my understanding that the rename was mainly done out of respect for the
original author and to acknowledge the new maintainership under the Tor Project
folks. So I think the roadmap for inclusion in Debian is like this:
• rename the source package and the principal binary package to Lyrebird but
retain the contents generally (preserving the old changelog should be possible)
• have that source package build an transitional package named 'obfs4proxy',
with a version matching the source package version, and which Depends on
Lyrebird
• have Lyrebird set Replaces appropriately, but after this I'm lost:
◦ If the binaries are renamed too and the packages are, in principle,
co-installable, I'm not sure what should happen after that, especially if Tor
needs to change its invocation in tandem anyway. If we ship a compatibility
symbolic link so Lyrebird can be invoked as 'obfs4proxy' then Breaks + Replaces
should be good (to help remove the old obfs4proxy binary package). Since they
work alike, though, we probably would want a 'Provides: obfs4proxy' then too?
I've not actually used this package before but I guess it comes down to whether
an automatic transition should, in principle, be possible.
(These rambling notes are for the benefit of Debian folks who want to know
what's going on with respect to the details. Don't concern yourself with these
technicalities now.)
> Is help needed? I'm not DD/DM, but I have worked with packaging few packages
> into Debian with sponsors, so I am willing to help too.
As an onlooker, I say "almost surely". Packaging software written in the Go
language requires some special care and the Debian Go Team's documentation
might help you if you're not familiar.
signature.asc
Description: This is a digitally signed message part
smime.p7s
Description: S/MIME cryptographic signature
