Hi, On 05/08/23 at 21:01 +0200, Sven Joachim wrote: > On 2023-08-05 19:31 +0100, Wookey wrote: > > > On 2023-08-05 17:06 +0200, Lucas Nussbaum wrote: > >> > >> I wonder what we should do, because 5000+ failing packages is a lot... > >> > >> Should we give up on requiring a 'clean' target that works? After all, > >> when 17% of packages are failing, it means that many maintainers don't > >> depend on it in their workflow. > > > > I still depend on this in my workflow, and it's very frustrating that > > a large fraction of packages are broken in this way. I'd love it if we > > had a bit of automation to tell people it's bust so they can fix > > it. Sometimes it is hard because build systems mess up your source > > tree, but a lot of the time it isn't. I have some sympathy for people > > who would have to do a lot of work to fight a build system that > > doesn't care about clean source trees if they don't care about them either. > > > > On the other hand it is a massive PITA when you build a package, and > > something breaks, and you try to build it again and it won't because > > the source tree has changed and the clean target doesn't actually clean. > > This happens way too often these days. > > It might be worth to consider changing your workflow a bit and work with > a git repository. It does not have to be a clone of the repository (if > any) where the package is maintained, you can start with a fresh import, > e.g. with "gbp import-dsc". > > Then before building the package for the first time, commit or at least > stash your changes, and you can go easily back to a clean state with > "git reset --hard; git clean -fdqx".
While this works in practice (and I do that as well), I find it hard to explain to new contributors that hacking on random packages requires them to create a temporary git repository so that they revert the package' source to a clean state. We already have a large pile of tools and worflows that need to be mastered when contributing to Debian. It would be better to avoid adding an additional one... Lucas
