That doesn't sound right to me; its legitimate topic that a package where the core use-case is X, that package has obscure feature Y, and the mere existence of Y can cause security issues for a user even when the user never intended to use it.

Very concrete example, the whole Log4j vulnerability issue was basically just a direct implication of a feature that allowed for arbitrary code execution. Nearly no user of Log4j intentionally used that feature, they were all vulnerable because Log4j had that feature.

The fix to the CVE was effectively to remove the feature. If someone had the foresight to try to reduce Log4j to only the features that ~everyone actually used, and publish a separate Log4j-maximal for the fringe users that intentionally use that feature, it would have prevented what was arguably the worst vulnerability that has ever happened.

In the case this thread is about, no one seems to be deny that there should be a 'minimal' and 'full' versions and that the 'minimal' version is going to be more secure. The entire flame war seems to be over whether its better to take a preexisting package name and have it be a minimal one or the full one.

That is simply a tradeoff between "make preexisting users who don't use ancillary features be as secure as possible by default going forward" or "make preexisting users who do use ancillary features not broken by upgrades".

> That doesn't sound right to me; its legitimate topic that a package where the core use-case is X, that package has obscure feature Y, and the mere existence of Y can cause security issues for a user even when the user never intended to use it.

In this case it is not clear at all whether the feature is obscure. For most people it could be actually essential and the primary requirement for the whole software.