[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Requesting input for pjproject/asterisk packaging

On Mon, 19 Nov 2018 23:40:44 +0100, Bernhard Schmidt
<berni@debian.org> wrote:
>1.) Drop src:asterisk and src:pjproject from Buster.

Worst option, cutting our users of from Asterisk totally.

>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

Those two options are bad as well, as it would cut our users off
community support, putting the support burden on Debian. In my
personal experience with the exim upstream community and Debian's
split config (which is really not a huge deviation from upstream
recommendations), the work load is not negligible.

>4.) Try to follow the path upstream has chosen with regards to the
>embedded pjproject library for Asterisk use.

My favorite. Our users would get the software _and_ upstream community
support. I concur with what Martin said.

 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

b. The multi tarball feature of dpkg-source would be helpful for a
number of other packages, it's about time that someone seriously uses
it. The downside is that we're rather late in the buster cycle and
don't have too much time to iron things out now.

a sounds lame ;-)

c sound like a nightmare. Didnt we have that for kernel modules?

-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Reply to: