Package Exclusion - Revision history

Michael Opdenacker: Just replace "blacklist" by "denylist"

2022-01-14T17:44:28Z

Just replace "blacklist" by "denylist"

← Older revision		Revision as of 17:44, 14 January 2022
Line 16:		Line 16:
	#* All error messages should be clear about which ''version'' of a package is being excluded not just the name (different versions may have different licences)		#* All error messages should be clear about which ''version'' of a package is being excluded not just the name (different versions may have different licences)
	#* Make the LICENSE validity checking more strict (given recipes have been audited and rules are clear after above)		#* Make the LICENSE validity checking more strict (given recipes have been audited and rules are clear after above)
	#* Don't exclude any recipes at parse time - simply record all excluded recipes and their runtime provides in a ~~blacklist~~ which also includes flags indicating the reason for ~~blacklisting~~		#* Don't exclude any recipes at parse time - simply record all excluded recipes and their runtime provides in a deny list which also includes flags indicating the reason for deny-listing
	#* Ensure all excluded licences in INCOMPATIBLE_LICENSE are valid (e.g. catch GPL3 as apposed to GPLv3) - if not, error out		#* Ensure all excluded licences in INCOMPATIBLE_LICENSE are valid (e.g. catch GPL3 as apposed to GPLv3) - if not, error out
	#* Check when calculating dependencies if anything is scheduled to be built that is on the ~~blacklist~~ - if any are, gather all of them up and then stop and list them in an error message along with reason and depchain for each one		#* Check when calculating dependencies if anything is scheduled to be built that is on the deny-list - if any are, gather all of them up and then stop and list them in an error message along with reason and depchain for each one
	#* Check when constructing the rootfs if anything in the runtime provides ~~blacklist~~ is going to be included - if so, error out		#* Check when constructing the rootfs if anything in the runtime provides denylist is going to be included - if so, error out

	Some further possible extensions:		Some further possible extensions:

PaulEggleton: Add link to Beth's work

2011-05-19T10:47:57Z

Add link to Beth's work

← Older revision		Revision as of 10:47, 19 May 2011
Line 1:		Line 1:
	== Introduction ==		== Introduction ==

	This page describes some proposed updates to the INCOMPATIBLE_LICENSE and COMMERCIAL* package exclusion mechanisms within Poky for the Yocto Project version 1.1.		This page describes some proposed updates to the INCOMPATIBLE_LICENSE and COMMERCIAL* package exclusion mechanisms within Poky for the Yocto Project version 1.1. See also [[License Infrastructure Interest Group]] for some overlapping work (particularly for the first part of the proposed implementation below).

	== Aims ==		== Aims ==
Line 10:		Line 10:
	== Proposed implementation ==		== Proposed implementation ==

	# Ensure all documentation of LICENSE field value syntax is clear, concise and up-to-date (wiki and manual)		# Ensure all documentation of LICENSE field value syntax is clear, concise and up-to-date (wiki and manual) [Beth/ScottR ?]
	# Go through and audit all recipes LICENSE field values to ensure that they all conform to the specifications. This includes making sure that \| (package may be used under one of a selection of licences) and & (recipe has mixed licences that apply to the code base, so conditions of all must be observed) are used correctly.		# Go through and audit all recipes LICENSE field values to ensure that they all conform to the specifications. This includes making sure that \| (package may be used under one of a selection of licences) and & (recipe has mixed licences that apply to the code base, so conditions of all must be observed) are used correctly. [Beth]
	# bitbake/core changes:		# bitbake/core changes:
	#* LICENSE field checking must fully parse the field and understand the difference between \| and &, and must not e.g. mark Qt as being GPLv3 only.		#* LICENSE field checking must fully parse the field and understand the difference between \| and &, and must not e.g. mark Qt as being GPLv3 only.
			#* All error messages should be clear about which ''version'' of a package is being excluded not just the name (different versions may have different licences)
	#* Make the LICENSE validity checking more strict (given recipes have been audited and rules are clear after above)		#* Make the LICENSE validity checking more strict (given recipes have been audited and rules are clear after above)
	#* Don't exclude any recipes at parse time - simply record all excluded recipes and their runtime provides in a blacklist which also includes flags indicating the reason for blacklisting		#* Don't exclude any recipes at parse time - simply record all excluded recipes and their runtime provides in a blacklist which also includes flags indicating the reason for blacklisting

PaulEggleton: Introduce new page for package exclusion

2011-05-10T16:30:19Z

Introduce new page for package exclusion

New page

== Introduction ==

This page describes some proposed updates to the INCOMPATIBLE_LICENSE and COMMERCIAL* package exclusion mechanisms within Poky for the Yocto Project version 1.1.

== Aims ==

* Make error messages clear when user/dependencies have asked for something to be built that can't be due to restrictions
* Ensure that exclusion system is reliable

== Proposed implementation ==

# Ensure all documentation of LICENSE field value syntax is clear, concise and up-to-date (wiki and manual)
# Go through and audit all recipes LICENSE field values to ensure that they all conform to the specifications. This includes making sure that | (package may be used under one of a selection of licences) and & (recipe has mixed licences that apply to the code base, so conditions of all must be observed) are used correctly.
# bitbake/core changes:
#* LICENSE field checking must fully parse the field and understand the difference between | and &, and must not e.g. mark Qt as being GPLv3 only.
#* Make the LICENSE validity checking more strict (given recipes have been audited and rules are clear after above)
#* Don't exclude any recipes at parse time - simply record all excluded recipes and their runtime provides in a blacklist which also includes flags indicating the reason for blacklisting
#* Ensure all excluded licences in INCOMPATIBLE_LICENSE are valid (e.g. catch GPL3 as apposed to GPLv3) - if not, error out
#* Check when calculating dependencies if anything is scheduled to be built that is on the blacklist - if any are, gather all of them up and then stop and list them in an error message along with reason and depchain for each one
#* Check when constructing the rootfs if anything in the runtime provides blacklist is going to be included - if so, error out

Some further possible extensions:

* Possibly apply similar logic to COMPATIBLE_MACHINE?
* Replace COMMERCIAL* with some more generic exclusion mechanism that allows the reason to be defined as part of the exclusion list?
* As a helper for non-en_US users, fail on parse if user defines any of the *LICENSE* variables as *LICENCE*? (we definitely don't want the build to continue and just ignore this as the user might not realise what has happened)