Re: Potential MBF: packages failing to build twice in a row
On Sat, Aug 05 2023, Lucas Nussbaum wrote:
> I wonder what we should do, because 5000+ failing packages is a lot...
Let's think about the level of trouble we cause trying to tackle
something that has clearly not bothered anyone for years.
>From the packaging side, there are many reasons that proper clean
targets can be difficult:
- Upstream wants to ship things that may get modified during build. Ie,
autoconf/automake replaces files they ship because they want it to
work "out of the box" in some fashion. Another example is
documentation; upstream may ship built docs even though we rebuild it
for completeness.
- Upstream's clean target is insufficient.
- Our own build processes make modifications. (eg, quilt; yes I know it
is supposed to be cleaned up but this is not always perfect)
- It is difficult to prepare a proper clean target, because build
artifacts may lack predictable names (eg, have the architecture
embedded in them)
Now, what are the possible options for dealing with this?
- Invest a lot of time writing bespoke scripts to handle it
- Copy the upstream source to a temp directory and build from there.
(Some packages already do this; if we are going to hack in this
direction all over, why not just do it by default everywhere?)
- Repack the upstream source to exclude files we generate. But this has
a ton of downfalls, including breaking the trust chain from upstream
to us. It should be a last resort (eg, making the tarball DFSG-free).
- Just tell people to run "git reset --hard HEAD; git clean -xfd"
Personally, I'm a volunteer. I have X amount of time to devote to
Debian. I work on Debian because I enjoy it. It is satisfying!
I maintain packages written in at least 6 different languages. Some
packages are sleek and modern tools. One I am about to take over traces
its codebase to 1981 and the upstream author has an explicit goal that
it still builds on operating systems that were discontinued in the
mid-80s.
I have an alias (not just for Debian) that does "git reset --hard HEAD;
git clean -xfd".
Spending hours to make a clean target I have no need for, already have
an equivalent of, and has no real purpose, drains my enthusiasm and
steals time that I could otherwise be using doing more high-value work
like fixing bugs.
Let's focus our energies on things that matter more.
> 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.
Yes.
- John
Reply to: