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
