Looking for advice on how to deal with potential slop packages
Michał Górny <[email protected]> Sat, 07 Mar 2026 11:38:03 +0100
| Newsgroups | dev.linux.lists.distributions |
|---|---|
| Organization | Gentoo |
| Message-ID | <[email protected]> |
--=-z1azW52OSxmOzGbU7N3x Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, everyone. Seeing more and more packages embracing LLM-driven development (to the point of "vibe coding" or slopware), I'm looking for your ideas on how distributions should deal with that. I'm basically torn between three things: 1. My duty towards the users to deliver up-to-date versions of software. 2. My duty towards the users to deliver *good* and *secure* software. 3. My ethical concerns, both directly related to LLM use, and to what people are using them for. As you may recall, Gentoo has already a strong policy prohibiting "AI" contributions [1]. However, this policy applies merely to contributions to the Gentoo projects themselves, and it does not affect the software we package. In fact, compared to binary distributions, Gentoo has had rather relaxed approach to what's acceptable, that could be summarized as "as long as it's not outright malicious and somebody is going to maintain the package". But over time, I'm having more and more concerns about the state of FLOSS in general. The first really doubtful case I've hit was the autobahn project. I've learned that it started using LLM-backend coding after it had a series of releases with *really weird* issues (like "how that could even happen?!" kind of issues) [2,3,4], and my bug reports were met with lots of AI slop generated replies, and pull requests that were also complete slop. I've eventually called the problem out, and upstream pretty much lashed at me [5]. Since then, I haven't pushed any new autobahn versions. While the issues I've hit were largely related to packaging, I have no reason to believe that the actual code is any better. So this is a case of rejecting slop on basis of low quality. The second big issue which you probably heard of is one of the maintainers of chardet using an LLM to rewrite the code while erasing the original autorship and changing the license, and then being an asshole about it [6] (you don't want to read that thread, it's complete shitshow with almost everyone cosplaying lawyers). Here the primary concern is copyright and ethics, but it also makes you wonder what the actual code quality is. Of course there are just two examples. There is a lot of projects using LLMs to various degree, and raising different concerns. On the other hand, I feel like a lot of these concerns existed before already, and it is just that we previously didn't pay attention that much. I mean, it's easier to say "they're using an LLM, it must be slop" than actually inspect the code and say "it's really bad quality". And people were being assholes long before LLMs. What are your experiences, thoughts and ideas how to deal with this? I mean, staying on old software versions and hoping people will change their minds (or more precisely, LLMs will stop being subsidized and people will have to start paying serious money for their usage) is not exactly a good idea. Going around and telling people "please switch from dependency X to Y because X is slop (and Y isn't yet)" doesn't sound like the best use of our time either. And forking? With the depressing state of FLOSS these days, I can't even find energy to maintain my own projects, let alone take anything else. [1] https://wiki.gentoo.org/wiki/Project:Council/AI_policy [2] https://github.com/crossbario/autobahn-python/issues/1716 [3] https://github.com/crossbario/autobahn-python/issues/1735 [4] https://github.com/crossbario/autobahn-python/issues/1782 [5] https://github.com/crossbario/autobahn-python/discussions/1818 [6] https://github.com/chardet/chardet/issues/327 --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-z1azW52OSxmOzGbU7N3x Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- iKQEABYKAEwWIQQcFD0bEK7NPNmWHtiOMjR69AVa6AUCaawACxsUgAAAAAAEAA5t YW51MiwyLjUrMS4xMiwyLDISHG1nb3JueUBnZW50b28ub3JnAAoJEI4yNHr0BVro GmcBAIZogGljsf33qn7MTnXSQ+B82Zm8YnW+bNABAiyet3imAP0ZBg99Y6hoRxex UDPzsCgLSYEFYX07sKTmQV7gtZu3BA== =ZqZr -----END PGP SIGNATURE----- --=-z1azW52OSxmOzGbU7N3x--