Package Exclusion

From Yocto Project
Revision as of 16:30, 10 May 2011 by PaulEggleton (talk | contribs) (Introduce new page for package exclusion)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

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

  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)