Add LICENSE visibility checks ("NonsolvableLicenseDeps")

pkgcore / pkgcheck

pkgcore-based QA utility for ebuild repos

https://pkgcore.github.io/pkgcheck

BSD 3-Clause "New" or "Revised" License

35 stars 29 forks source link

Add LICENSE visibility checks ("NonsolvableLicenseDeps") #471

Open thesamesam opened 2 years ago

thesamesam commented 2 years ago

It's possible for the tree to become "broken" by a package that has @FREE licenses suddenly gaining a dependency which is not in @FREE.

Example (covered at https://bugs.gentoo.org/832778).

GNOME depends on app-accessibility/orca (LICENSE has only FOSS licenses contained within the @FREE set) for accessibility support
app-accessibility/orca started to depend on app-accessibility/espeak-ng in a new version instead of app-accessibility/espeak
app-accessibility/espeak-ng initially had a non-free licence
This meant anyone with GNOME installed (with the right USE flags, anyway) pulling in Orca couldn't upgrade fully because espeak-ng could not be emerged.

We should have some way of detecting this via pkgcheck, as it's just as valid as dependencies otherwise being unresolvable (e.g. via keyword), and more serious even than RequiredUseDefaults IMO.

thesamesam commented 2 years ago

A quick way of making a bad ebuild which breaks the tree:

Create an ebuild sys-apps/foo with LICENSE="all-rights-reserved"
Add it to @system in profiles/
Try to do a world upgrade

arthurzam commented 2 years ago

I can perform the check, by each package checking it sub packages. But, what should be the correct behavior here? In theory I see no issue with a free software depending on non-free software (of course not in "base" profile system). Or am I wrong? I'm asking about "false report" cases here.

Also, if we say we should go with it, what level should it be? Should it be error and fail croacker?

ajakk commented 2 years ago

https://bugs.gentoo.org/872119 is one such example of an issue resulting from this.

thesamesam commented 2 years ago

I can perform the check, by each package checking it sub packages. But, what should be the correct behavior here? In theory I see no issue with a free software depending on non-free software (of course not in "base" profile system). Or am I wrong? I'm asking about "false report" cases here.

Also, if we say we should go with it, what level should it be? Should it be error and fail croacker?

Maybe it could be like RequiredUseDefaults where we shouldn't have it be by default. This minimises the impact to users from such incidents like the linked bugs (it should hopefully pick them up). In such cases, it should be a warning.

Additionally, I think we may want a general warning for something with @FREE depending on non-@FREE, but this could be a 'style' level warning to avoid noise. I think it's useful for someone to know when packaging/adding a new dep that something is non-free, so they can inform upstream, etc.

arthurzam commented 2 years ago

Maybe it could be like RequiredUseDefaults where we shouldn't have it be by default. This minimises the impact to users from such incidents like the linked bugs (it should hopefully pick them up). In such cases, it should be a warning.

OK, but this will notify for all non free packages in tree. I think we need to define which set of packages to scan.

Additionally, I think we may want a general warning for something with @FREE depending on non-@FREE, but this could be a 'style' level warning to avoid noise. I think it's useful for someone to know when packaging/adding a new dep that something is non-free, so they can inform upstream, etc.

This one is understood and would be added.

thesamesam commented 2 years ago

Maybe it could be like RequiredUseDefaults where we shouldn't have it be by default. This minimises the impact to users from such incidents like the linked bugs (it should hopefully pick them up). In such cases, it should be a warning.

OK, but this will notify for all non free packages in tree. I think we need to define which set of packages to scan.

It's okay if the leaf package is non-free. It's not okay if a package with LICENSE only consisting of @FREE has a dependency which isn't.

I don't think we need to worry about non-free depending on non-free.