On Tue, Jan 07, 2025 at 10:23:12AM +0000, Ian Jackson wrote: [..] > One piece of background that is heavily influencing my thinking is: > > It is easy, when working within Debian, to radically overestimate the > likely quality of non-Debian packages. I have done some work with > packages in the rpi ecosystem (I'm thinking of packages *not* part of > Raspbian, which has source from Debian), and also other upstreams. > My experience is that packages written by people not steeped in Debian > culture, and that aren't subjected to Debian's various QA processes, > often only resemble normal Debian practices in the vaguest sense. > > This is to be expected. Debian packaging is complicated, and can be > weird. People working outside Debian are just tryilng to get shit > done and don't have time to learn how to do it properly. They hack > something together until it works.
[..] > Some downstreams and users will have their own build processes. > CI jobs, rebuild robots, and the like, which build packages > automatically. In such a scenario, an option or env var to restore > compatibility with existing packages, without having to add a step to > the build to mess with the source package, will be very helpful. I'm sympathetic to keeping existing out-of-Debian packaging working, but I just have to note two thoughts: 1) actual downstreams are used to dealing with changes in Debian all the time. 2) users with CI jobs are, too. Depending on what their exact setup is they'll already have noticed, or they pay the cost when changing the distribution name in their config. 3) users that have neither and just hack something together won't set a new environment variable that they will not hear of. Worse, at some point this environment variable will go away again, and then they had to do work twice. Best, Chris
