Re: Potential MBF: packages failing to build twice in a row
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
Reply to: