Am Mi., 11. März 2026 um 01:56 Uhr schrieb Sam James <[email protected]>: > > Kai Krakow <[email protected]> writes: > > > Am Di., 10. März 2026 um 16:55 Uhr schrieb Michał Górny <[email protected]>: > > [...] > > > > But realistically, there isn't a chance for Gentoo to avoid every > > possible AI or LLM assisted contribution to Gentoo through packages or > > direct contributions. > > Right (see below too), but I think the best we could do here is allow > some users to go an extra step and avoid such packages, though I think > it's less pressing than having some way of marking chardet etc as > tainted and not something we should depend on >= tainted versions for.
Yes, meanwhile I've looked at the links, and that situation really looks bad. Especially for autobahn, it looks like the developer isn't even transparently communicating when an LLM is used, and when not. It is clearly visible by the style of comments. The developer doesn't even understand the point. This is one of the worst signals. > The purpose of the discussion is to figure out what to do with packages > that fail such quality gates, though, and by what mechanism to do that. I apologize, I drifted away from the core of the discussion. IMHO, there's clearly only one short-term solution: Do not bump the package or mask the newer version. But we have to face the situation that sooner or later, upstream packages will depend on the newer versions. One question would be, why does it happen? - Has the quality of the dependent package improved so anyone can use it? That would be the best outcome. Looking at the current examples, what could good quality gates be, how do we anchor them in portage, and how do we let users decide what to block without creating dependency hell? If the package in question has an easy replacement, I'd say: Just drop it even if we lose a feature that way. If interest is high enough, a fork may be a good solution. But that shouldn't be the burden of Gentoo. It should be a cross-distribution, community-wide effort. It probably requires bringing such issues to more attention, maybe through a blog post, but in a politically correct and fair way. I think a very simple quality gate like LICENSE=AI-SLOP may not be enough (I don't intend to support the wording "AI-SLOP", it should probably be discussed more). Users should be able whether they want to block AI-assisted code at all (which may be a futile effort but that's a different discussion), whether they accept AI-assisted or vibe-coded but human-reviewed packages, or whether they don't care at all. Gentoo should probably also not accept "AI slop" packages into the main portage tree at all. But that doesn't solve the problem when packages switch over to such a discouraged development style later, and it restarts the efforts of handling such a package. So we'd probably also need quality gates which take into account what the development history of the project is, and how well organized it is. Single developer projects may always be problematic, for whatever reasons - it's not only AI slop. I think xz-utils was one such example. I'd argue that single-developer projects more likely tend to introduce AI in a sloppy way into the project. So Gentoo should be careful about such projects by trying to avoid digging such packages deep into the dependency tree. The question is, what do we want to achieve? - Easy removal of packages gone bad? - Easy blocking of packages because of ethical reasons? Isn't this question about how to handle such packages really about "how to avoid deep dependencies" rather than "how to avoid AI"? A package can go bad for several reasons, not just because of AI slop. > > But I also think that Gentoo's future is not denying that AI exists or > > refusing AI involvement. It will become a tool that cannot be avoided, > > and we have to deal with it in a reasonable way. AI/LLM is still an > > early tool that humans have to learn to use correctly. Currently the > > situation is: It's not used correctly. > > Yes, I tend to agree. > > But what do we do when it's not being used correctly? How do we respond? I'm not sure if Gentoo can do anything about the package itself - we do not control it. We can only try to keep the potential impact low. > How do we decide what the line is? And how do we communicate this to > users (possibly allowing them some choice in the matter) and other developers? Since Gentoo is strongly about choice, we should at least give them a choice of: - avoiding potentially weakly supported packages carried by just one single developer It's important here to make clear that this doesn't mean a single developer is a bad developer. But I think we can agree that this is a burden. I think such packages should be supported better, maybe by offering sponsorings, under predefined policies (like not going the AI slop way). - avoiding installing packages with several degrees of AI involvement I think it's fair to respect the several concerns of users, especially regarding ethical concerns. But this needs careful planning. It's already easy in Gentoo to create avalanges of dependency hell just because one flipped a use flag. The core dependency tree (probably the system set) should stay as clean as possible. Looking at dev-python/autobahn: It doesn't seem to have reverse dependencies. What's the point of having it in the portage tree then, anyways? It could be moved to GURU if it is important to some users. >From my personal experience as a software developer, I try to avoid system-installed packages as dependencies as best as possible, I usually keep a consistent development environment using pip, distrobox, rvm or other. So if I had a development project which depends on autobahn, I'd probably not install it as a system lib anyways but rather in an isolated development environment where I control the version and when to bump. One other thing is that the referenced "AI policy" in the linked issue reports doesn't even exist: https://github.com/crossbario/autobahn-python/blob/main/AI_POLICY.md. So what's the policy here even? BTW: It's actually in the repository, but the link is broken, and even then it's still one more indirection. And it's clearly written and authored by AI itself, so it seemingly violates itself, it has all the signs of being produced by an LLM. The situation with chardet looks different: Some core packages depend on it. What would be an effort maintaining a fork of it for the sake of the core packages? It probably doesn't need a lot of attention. And a fork may attract other contributors which don't agree with the current development. Of course, this solution cannot be carried through all such future issues that *will* happen. I'm not sure if a generic solution is possible. This will often be a case-by-case decision. And Gentoo could have an easier future by carefully curating what the core dependencies are. Regards, Kai
