RFC: Package exclusion

[Paul Eggleton <paul.eggleton@linux.intel.com>]

Hi all,

As part of the 1.1 feature list I suggested a review of the 
INCOMPATIBLE_LICENSE and COMMERCIAL* package exclusion mechanisms we have 
within Poky. Below I've outlined my ideas and would appreciate any 
comments/additions/corrections.

==== 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 ==== 

 1) Ensure all documentation of LICENSE field value syntax is clear, concise 
and up-to-date (wiki and manual)

 2) 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.

 3) 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)


Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre