Re: Potential MBF: packages failing to build twice in a row
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".
> As you say it's clear that a lot of people are not doing things this
> way any more, but a clean target that works still has significant
> value for various sorts of automated builds, and debugging stuff.
> Perhaps an alternative to keeping the clean target working for people
> who don't care about maintaining it, is some metadata to say 'this
> package can only be built reliably from git/VCS - the old debian stuff is
> bust'. Better would be a new git-only dpkg format of some sort with a
> new set of expectations. But that's quite a big piece of work.
>
> Just to be clear I don't want any of that. I want the existing tooling
> and packaging to work the way policy says it should, at least until it
> is agreed that policy has to change.
You can want whatever you like, but wanting does not make anything
happen magically.
Cheers,
Sven
Reply to: