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
