Re: Steam Deck: good news for Linux gaming, bad news for Debian :(
Hi,
On Thu, Aug 12, 2021 at 02:06:37PM +0200, Romain Porte wrote:
> > Looking at Arch, one workflow, one way to package, one init system, etc.
> > Looking at Fedora, one workflow, one way to package, one init system.
>
> I think this is a major point. I am a new Debian contributor after a
> good time of ArchLinux PKGBUILD writing. I find Debian technically
> superior on the packaging side, and would not trade it for PKGBUILD. But
> there are so many ways to do things. After a lot of exploration, I have
> found that the tooling that I was the most comfortable with was:
>
> * Salsa VCS
> * GBP for git + patching (+ DEP-conformant branch names)
> * dh
>
> However there are so many other ways to do things. Some packages are not
> on Salsa. Some packages use manually generated diff files. Different
> branch names everywhere (debian/latest vs. debian/master vs.
> debian/unstable vs. master…). I think progressive enforcing of a
> workflow would help new maintainers to not be lost in the packaging jungle.
Amen.
> > I still trust Debian to be the most technically excellent distribution,
> > but that's not all it makes to stay relevant. My point is that it would
> > help to reduce the technical liberties we take in Debian. However, I
> > don't think that's who we are.
>
> Maintainers like their freedoms, but enforcing some tools at some point
> could make it easier for everyone to contribute and not relearn the
> packaging process for every package, because currently every package is
> different. We are getting there by looking at the number of "3.0
> (quilt)" packages and "dh" usage, but when a package does not conform to
> this norm, it triggers a mental freeze on my side (and I want to migrate
> it all to dh/3.0 quilt etc.).
+1
May be we start defining workflow recommendations in policy or we draft
some development policy. I'm aware that there are may be < 100 packages
inside the Debian package pool that are hard to push into some default
shape - but most packages with "unusual" workflows are that way for no
good reason.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: