Kai Krakow <[email protected]> writes: > 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.
No worries, it is easily done. > > 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. > I think we can avoid this in some cases by lobbying upstreams and proposing alternatives. Not always, though. > 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. I was thinking a bit about this earlier, and I guess the difference here is the scale with which we're seeing these things happen. Occasionally sometimes an upstream goes rogue or makes an odd decision but it doesn't happen that often, and it doesn't happen to many projects at the same time. The speed with which you can destroy a project and its reputation has maybe picked up too :) > > >> > 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. > Our users do rely on us to keep them safe from serious bugs, security problems, and so on. This is an extension of that. So, I don't think we can just package new versions without much thought and without any mask or marker, at least not in all cases. Just in this thread we're trying to figure out what our options are and the range of responses we have (and trying to categorise what the scenarios we're likely to hit are). > >> 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). I think we run the risk of unnecessarily antagonising projects with that, even if I get where you're coming from. > > - 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. Yes, just like with LICENSE, users may well have quite a strong philosophical position on this and I want to try facilitate that as much as is feasible (which may mean they just can't use certain packages, not saying we're going to fork everything). > > 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. It has a few in ::gentoo, like dev-util/buildbot. > 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. Yeah, I think for chardet, pinning and possibly forking with minimal changes, and then if required, having reverse dependencies port to charset-normalizer will work. We'll have to limit this kind of thing to severe cases though, not sustainable otherwise. > > 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. Right. > > Regards, > Kai thanks, sam
signature.asc
Description: PGP signature
