Bug#1031046: Only include in Bookworm with commitment to stable updates

[Jonas Smedegaard]

Quoting Matthias Urlichs via Pkg-voip-maintainers (2024-12-13 08:56:18)
> On 13.12.24 01:08, C. Maj wrote:
> > Unfortunately, the current Asterisk on Debian build process is, shall 
> > we say, cumbersome to reproduce independently. Shining some light on a 
> > basic outline of the *current* steps used would be most helpful. 
> 
> It'd be *very* helpful if you could spend some work to make all these 
> steps unnecessary in the first place.
> 
> The outline (and what I'd do if I had less than zero free time *sigh* to 
> improve the situation) is, as far as I could determine:
> 
> * The Asterisk build includes four vendorized git archives: pjsip, mp3, 
> and Asterisk codec+format support for amr and opus. These are unpacked 
> to toplevel "X…" directories.
> 
> pjproject is on version 2.14.1 and merely gets "unbroken" by removing 
> the build of "bdimad_dev.o". Could the pjproject stack be packaged as 
> "real" Debian packages instead, as AFAICT Asterisk seems not to require 
> a patched pjproject any more? Does Asterisk work OK with pjsip release 2.15?
> 
> The AMR and Opus codecs get patched into main/codec_builtin.c et al. 
> Given that everybody and their dog does this, could upstream Asterisk 
> please incorporate github.com:traud/asterisk-opus.git and …-amr.git?
> 
> Likewise, the mp3 part is a trimmed-down version of libmpg123, which by 
> now is in Debian anyway. Please investigate what's required to simply 
> use that instead.
> 
> * the whole kaboodle is then packaged into a bunch of tar files.
> 
> * Next, during build, variouos patches are applied. Then the Xpjproject 
> directory is repacked to third-party/pjproject/pjproject-VERSION.tar.gz 
> (with an "adjusted" checksum file) so that the Asterisk build process 
> finds it.
> 
> * If this process does any work to remove non-DFSG-free material, I 
> didn't notice. Admittedly I didn't go out of my way to look for that 
> part either.
> 
> * I already wrote about my opinion WRT pristine-tar, debian/patches, and 
> all that. To summarize, I strongly advocate to base your workflow on 
> your normal Asterisk git releases, to use a git-centered workflow 
> instead of quilt, and to not reproduce Debian's current Asterisk 
> archive. It's not necessary.
> 
> To that effect, it'd help if you'd push *signed* git tags whenever you 
> release Asterisk.

Fully agreed on the above.

While I do understand that you from an upstream point of view can have
difficulties figuring out how the build routines in Debian works, they
are general to Debian, and the parts that I complex compared to other
Debian packages is due to upstream complexities.

One thing I can add is that it would be helpful if you did not embed
external sources but also did not require the use of git submodules or
similar tricks: Allow for linking against system shared libraries - also
for components that you yourself choose to fork and patch before linking
against it, and also for components that you yourself choose to link
statically against.  Allow for distributors to handle themselves where
in their maintenance chain they choose to apply patches, and how they
choose to link against other projects.

I packaged pjproject as a separate Debian library package some years
ago, but others it this team at the time deemed the asterisk build
process too complex to link with straight up standard ordinary C/C++
shared library available in the system.

The pjproject debian package was abandoned in favor of a complicated
repackaging routine baked into the asterisk package, which alienated me
from maintaining the package. This is one reason for my bailing not
contributing to security patching of the package that is now in
oldstable and since few months no longer in official Debian: The process
of unpacing sources was too complex and too unique for me to follow
(I am involved in maintaining 700+ packages in Debian, and it is a
major pain for me to handle unique packaging routines).

I then normalized the asterisk package to a (still complex but) more
common Debian style - i.e. using uscan and git-buildpackage to
repackage source instead of a custom shell script.  Unfortunately that
alienated the packaging routines for the guy who implemented the earlier
custom shell script, so we had a situation where one single person was
maintaining the package in unstable/testing, and one single *different*
person was maintained the package in oldstable.

The cause of this mess is, from one view, that Debian is weird and
strange and should just get rid of itself and use Github. From another
view, the cause is that this one specific upstream source is weird and
strange compared to most of Debian, and should just get in line and use
tarballs and support shared linking.

Until either Debian stops being Debian, or Asterisk stops embedding
PJProject, the asterisk package is somewhat confusing to unpack.
I am volunteering to do the task of importing new upstream releases
and turning that into a Debian source package, and have done that
steadily for a few years now.  What is needed, short-term in Debian, is
other parts of the maintenance.  What is needed long-term is up in the
air, but could be Debian reinventing itself, or Asterisk streamlining
its sources, or me vanishing and someone else replacing the
git-buildpackage routines with something custom in Vala or Haskell.

Ok, I will stop my rant now... :-)

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private