RFC: Package exclusion


Paul Eggleton
 

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

Join yocto@lists.yoctoproject.org to automatically receive all group messages.