
Debian Janitor: 60k Lintian Issues Automatically Fixed - zdw
https://www.jelmer.uk/janitor-update-3.html
======
cookiengineer
To be honest, this sounds more like a >/dev/null solution to me. The
underlying issue is that debian packages are out of date, and that the repos
(ppas) containing them are heavily unmaintained up to the point were decades
old libraries are required even when upstream has moved on.

Why not go with the approach to try and fix it upstream where it belongs
instead of maintaining a set of fixers downstream - which will likely not work
anymore in the forseeable future?

I mean, if you start building an auto-fixer pipeline for an auto-linted
error... then is that error actually valid in the first place? Probably not.

The reason why a lot of developers these days have moved to Arch's/AUR's
ecosystem is not the amount of available packages (they probably are around
the same) - It's integration of packaging with upstream.

Every time a package upstream is out-of-date or not working, you'll likely
find an Arch user trying to fix it with a pull request in the git repos.

The debian janitor should've tried to automate pull requests rather than
trying to automate self-hosted fixes downstream without letting upstream even
know that their packages are wrongly formatted.

But that's just my two cents, maintained a lot of PPAs in the past for both
Debian and Ubuntu and have moved on to Arch/Manjaro, because I ain't got no
time for that anymore.

~~~
xioxox
Though a lot of these errors are in the package metadata, Debian doesn't make
it easy for itself as the build system and packaging format is very complex.
There are lots of different build system variants, relying on weird poorly-
documented helper scripts which have strange interactions. In my opinion,
there's just too much magic in the debhelper system to understand how to fix
problems. You also have the long, complex and constantly changing list of
rules which need to be applied for each update. They are very strict about
noting down the copyright of all the files, for example (which I can
understand to some extent).

I think the biggest issue is the social problem of the long and arduous
process to become a trusted Debian Developer. Although there's now an easier
Debian Maintainer option for restricted access, it's still not easy to become
one. Other people have to go through a developer to update or add packages. If
you can't find a responsive developer, then package changes can sit for months
or years in a broken state before they are applied (as I have found out). The
whole packaging process is a frustrating exercise in bureaucracy compared to
other non-Debian distributions (e.g. Fedora), which is no fun to be involved
in for most people.

~~~
debiandev
> weird poorly-documented helper scripts which have strange interactions

I've never found a packaging tool without an extensive and clear manpage with
examples.

> I think the biggest issue is the social problem of the long and arduous
> process to become a trusted Debian Developer. Although there's now an easier
> Debian Maintainer option for restricted access, it's still not easy to
> become one. Other people have to go through a developer to update or add
> packages.

There is an arduous process to become a senior engineer in a FAANG, or a
tenured professor, or an airline pilot.

That's why a lot of people trust Debian.

~~~
bhaak
> I've never found a packaging tool without an extensive and clear manpage
> with examples.

That might be fine if you already know which packaging tool to start with.
Debian has several and it's not clear upfront which one is the preferred one.
But even then I'd say that there is something like too much information.

And the process is complex. If I want to package a standard autoconf/cmake
program, I have to do a lot of command typing. If you compare that to Gentoo,
Arch or even Homebrew packages where you essentially edit one file and one or
two command invocations, that's just cumbersome.

I recently tried to find out what I would have to do to for a NMU and I just
couldn't find any entrance point that made sense to me. It felt like trying to
get into a cabal and all the information is encoded in arcane Latin.

~~~
jelmer
The process is indeed complex, but there are efforts to standardize on a
single simple way to do packaging. Unfortunately with an archive of 30k source
packages, that is a slow process.

A great resource is [https://trends.debian.net/](https://trends.debian.net/),
which tracks some of the different ways of doing packaging, as well as the
progress on convergence.

With the new style debhelper that we're converging on and a straightforward
package, creating a new package should not have to involve a lot of typing -
although it's still split across multiple files.

------
Pubbian
Yes indeed Pubbian

------
Pubbian
Pubbian

