James Le Cuirot <[email protected]> writes: > On Tue, 2026-03-10 at 17:16 +0000, Filip Kobierski wrote: >> Hi Michał, >> >> The issue you described is real and widespread. >> >> Maybe one could flag slop packages with a LICENSE variable that is not >> accepted by default? >> That would allow users to still have the final say in what can run on their >> Gentoo systems but would be aware that AI-SLOP license is suboptimal. >> Then I imagine the problem would be in marking packages as such... >> Also the name of the "LICENSE"; AI-SLOP seems in-line with Gentoo's >> approach, alas I in my opinion is unprofessional. Plain AI does not really >> sound discouraging. Naming is a secondary issue though. >> >> What do you think about that? > > If a maintainer dislikes something about a project strongly enough to stick > this kind of warning label on it, then I imagine they won't want to maintain > it anyway. If it's a dependency of something they care about, then they could > pass it onto someone else, although they may still be unsatisfied with that. I > don't know what else to suggest. Forking is not the answer, as mgorny has > written elsewhere. > > If they're otherwise willing to hold their nose, I think a simplistic label is > not going to be sufficient. Different projects are doing different things, and > it's not fair to tar them all with the same brush. In addition, everyone has > different opinions and tolerances around this. I personally think what chardet > did was irresponsible, but I don't have an issue with what KeepassXC are > doing. I therefore think the best thing to do is have a free text field in > metadata.xml where a maintainer can fully express any concerns along with > links to evidence, much like what mgorny has done here. That way, users can > make their own fully informed decisions.
OK, but what do we do about the dev-python/chardet case? How do we signal to people that they shouldn't bump to it and shouldn't depend on >=7 (the bad version)? We can rely on people "just knowing" for chardet because it's maintained by @python, but what do we do for maintainer-needed packages say in this state? Your stance works (somewhat) for leaf packages, to some extent. It doesn't work for two other cases: 1) where users wish to avoid such packages and have a standard way of finding out about it (let's ignore KeepassXC for now, as I think it's contestable enough); 2) other packages depending on it and needing to lobby upstreams or patch downstream to avoid >= deps on something infected I'll write this up separately.
signature.asc
Description: PGP signature
