Requesting input for pjproject/asterisk packaging
Hello everyone,
I'm seeking packaging guidance for a package (combination) I co-maintain
since shortly before the Stretch release. I'm not quite sure how to deal
with this situation in a way best for everyone involved (especially
release managers and security team).
Asterisk is probably known to most of you as the most widely deployed
OpenSource PBX. The project has been around for ages. In the Asterisk 13
release (which is in Stretch) they more or less set their old homegrown
SIP stack (called chan_sip) to maintenance only and offered an
additional, new channel driver called chan_pjsip as
replacement/successor. This one does use an external SIP library called
PJSIP. It is packaged in Debian as src:pjproject.
PJSIP is a package maintaining nightmare. A lot of behaviour
functionality you need to set to use it with Asterisk is by setting
#defines in a config file at build time (see
https://salsa.debian.org/pkg-voip-team/pjproject/blob/master/debian/config_site.h).
Most of these settings change the ABI because they are embedded
everywhere in structs. Library symbols come and go with new upstream
releases because upstream does not control exports in any way. It has
only been manageable because src:asterisk is the only rdep.
There is also a python library built from src:pjproject, but as far as I
can tell the one we ship is already abandoned upstream and another one
with the exact same name but different API has taken it's place. :-(
There is one other source package in the archive that already uses an
embedded copy of src:pjproject, src:ring. There has been a short
discussion with the ring maintainers just before the Stretch freeze to
use src:pjproject (Bug#843654), but since both Asterisk and ring
need(ed) their own set of patches and config.h settings in pjproject it
was abandoned. Basically src:pjproject only lives in Debian for the use
by Asterisk. I'm not aware of any other embedded code copies.
Asterisk maintainers have first offerered, then recommended working
around this issue by shipping a private copy (actually, a download of
the original pjsip source during build, enhanced with a couple of
patches mostly retrieved from pjsip SVN) of pjsip for Asterisk use. It
wasn't mandatory though, so we built against the system-wide pjproject.
We have heard that with the upcoming release it will actually require or
at least strongy suggest using the bundled pjproject. It will be built
with a different name (libasteriskpj), so it would not conflict with
another pjproject installation.
Oh, and as additional complexity, both asterisk and pjproject currently
need to be repacked due to non-DFSG-free third-party stuff in the
original tarball and occasionally have security bugs that need to be
fixed. And src:pjproject currently has a lot of dependencies to other
external libraries that are disabled in the Asterisk build (because
Asterisk handles this internally, i.e. video or SRTP).
As far as I can tell we will have the following options for Buster
1.) Drop src:asterisk and src:pjproject from Buster.
2.) Keep the current pjproject and Asterisk version and don't follow the
upgrade. This will probably be harder as it sounds, as Asterisk 13 LTS
will be EOL soon. Asterisk 16 will be/is the next LTS. Backporting the
security fixes has already been non-trivial from 13.2x to 13.14.
3.) Upgrade src:pjproject to 2.8 and Asterisk to the upcoming 16.1,
somehow patching the build process to still use the system-wide
src:pjproject libraries. This is probably doable, but not supported by
upstream.
4.) Try to follow the path upstream has chosen with regards to the
embedded pjproject library for Asterisk use. Since the build process
downloads the pjproject source code which is a no-go we need to find a
way to inject the pjproject source code into the build. Since it is not
DFSG-free we cannot include the tarball in debian/ as is.
a) Add a dfsg-repack tarball into debian/
b) try to somehow use the multi tarball feature from dpkg-source, but
it is still marked experimental for git-buildpackage and I honestly
think this would be major pitfall for maintenance
c) build something like pjproject-source:all from src:pjproject,
build-dep on that from src:asterisk. This way a security issue fixed in
src:pjproject would need a binNMU of src:asterisk
In this case we could drop most of pjproject from Buster (either
completely or except for the fictional pjproject-source:all), because I
don't see any use of it outside of Asterisk.
5.) ???
Thanks for any input.
Bernhard
Reply to: