Allow asterisk to build on bookworm without bookwork-backports (systemd-dev dependency)

[Jonas Smedegaard]

Quoting Matthias Urlichs via Pkg-voip-maintainers (2024-12-12 05:30:21)
> On 12.12.24 01:30, Jonas Smedegaard wrote:
> > that some people (not you, those not showing an interest in stability)
> > prioritizing backports over the very stuff that makes it possible to
> > backport: something that is stable in the first place, as a foundation
> > e.g. for such simpler and shorter-lived efforts of backporting.
> 
> I can only assume that you mean me by "some people".

Sorry, I can see how my attempt at emphasizing the work ahead has
turned my arguments into a blaming game.  Sorry, José, for throwing mud.

No, I did not mean you, Matthias. I meant to jokingly differentiate the
virtual José that I had imagined through quickly browsing my email
archive from the José in this conversation - because although they
technically use same email address, one of them clearly have an interest
in this team - not only now but also earlier - having joined the team
some time ago after a previous round of emails mostly in a bugreport.

Let me emphasize: I am happy that you are both here, and that you are
interested in helping out.  And I am perfectly fine with any of you
having interest in other packaging styles or other distros.

What I find frustrating is suggesting approaches other than official
Debian packaging as possible solution for the official Debian package.
Debian cannot be backported to Debian, it has to be created.  That is
not a religious standpoint (which I frankly find that the term
"intellectually-pure" is getting at), but just plain practicality: This
team is maintaining a component of Debian itself, not maintaining a
thing outside of Debian to be applied onto Debian however convenient.


> I acknowledge that this is one way of looking at it, though I contest 
> that I'm very much "interested in stability".
> 
> However. I'm not using Debian because I like intellectually-pure 
> packaging. That's secondary to actually getting some work done.

I also have different priorities than Debian values in my Debian *use*.

My involvement *in this team* is, however, bound by Debian values.


> If the 
> current packaging gets in the way of that, then my first step *has to* 
> be to side-step some of it, for the simple reason that I'm not getting 
> paid when my company's phone system stays broken.
> 
> The third step is to do this in such a way that the result isn't just a 
> one-shot effort. The second step? figure out a way to spend the least 
> possible effort on achieving step three.

We all have other priorities in life than Debian, outside Debian.  Makes
sense to step aside when those priorities kick in.  Please do!


> Speaking of long-term stability: My core assumption is that the number 
> of people who can do a quick "git pull upstream; fix conflicts if any; 
> test; be happy; git debpush" (plus "git rebase" and fake-merging when 
> there's a new Upstream release; in other words, the "git debpush" 
> workflow) is strictly greater than the number of people who can and/or 
> want to deal with pristine-tar and quilt. The nonexistence of a stable 
> Asterisk .deb is not the only symptom of that. IMHO.
> 
> Thus, *my* view of a foundation for "stable and sustainable work" 
> happens to be an upstream git tree with a minimum amount of changes to 
> build DFSG-clean Debian binaries. If some additional work is required to 
> wrangle the result into the shape that the current(!) Debian build 
> infrastructure insists on (Asterisk does depend on a number of 
> vendorized libraries and some other special sauce (DAHDI …)), fine, 
> let's talk about how to do that.

Thanks for sharing.

Do you say that you personally prefer to use git-buildpackage *without*
the pristine-tar option and with debpush option instead of quilt?

I ask because it seems you are not saying that you want that, but
instead that popular demand gravitates towards less Debian-specific foo,
which is a different argument.  That same argument can lead to another
conclusion as well, which I am open towards long-term (but not right
now): One of the dgit-based workflows (not sure which, and I want to
postpone that conversation unless some of you have a pressing urge to
discuss it immediately).


 - 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