Hi,
I have some questions also.
1) How do I create two different builds into the toaster.sqlite database? Can
the 'poky/filec/tmp' directory contain two completely different image, machine
builds by just revising file/conf/local.conf?
This impacts the traverse differences between
'all package' path, 1.5.1 Package Details (from dashboard -> all packages ->
package detail)
vs
'image information' path, 1.1.1 Included Package Deatils (from dashboard ->
specific image information -> Included package details).
2) Since I can’t get more than one build loaded into toaster.sqlite, I seem to
only be able to navigate to ‘Included packages’. I can't follow the 'the all
packages -> package'. Is that correct?
3) The specs for 1.5.1 state that the multiple licenses (and license paths)
should be listed for each package.
"3. License files: location [on] disk of the package license files (if any).
We should display the generic licenses first, in the same order as they appear
in "License" [another field described in the spec]. Then, the package-specific
license (LICENSE, COPYING, README, etc), followed by any source files (in
ascending alphabetical order)."
The ORM (entity-relation) model of the database isn't setup to support an
N-to-1 License-to-package relation. Instead there is only package.license, and
the package.license fields unfortunately contain '&' and '|' in the
package.license field, instead of using a relation table package-license that
would have foreign keys.
sqlite> select license from orm_package where license
like "% & %" OR license like "% | %" GROUP BY license;
AFL-2 | GPLv2+
BSD | Artistic-1.0
GPL-2.0+ & LGPL-2.1+
GPL-3.0-with-GCC-exception & GPLv3
GPLv2 & LGPLv2 & BSD & MIT
...
I traced this back to the LICENSE assignments explicitly listed in the recipes,
for example in meta/recipes-core...
recipes-core> grep -R "LICENSE = " * | egrep "&|\|"
...
dbus/dbus-glib.inc:LICENSE = "AFL-2 | GPLv2+"
dbus/dbus-ptest_1.6.18.bb:LICENSE = "AFL-2 | GPLv2+"
dbus/dbus.inc:LICENSE = "AFL-2 | GPLv2+"
...
The build creates licenses in package specific directoreis:
licenses> ls $PWD/dbus*
(...)filec/tmp/deploy/licenses/dbus:
COPYING dbus.h generic_AFL-2 generic_GPLv2
So per sepec, the views must handle and display a list of {license-name,
license-type (generic or specific), license-directory-path} tuples. This is
not currently in the model. There are two implementations that I've
considered:
1) modify the model, that is, the schema, and event handlers that load the
schema, to directly support the view specs, or
2) provide workaround helper functions in the model Package class.
For (1), my preference,
* we (almost) normalize the database:
- remove package.license,
- add license-for-package class
{id, name, license-path, package_id foreign key}
* add a new function get_license_data(d) into license.bbclass, similar to
license.bbclass:find_license_files(d) called
buildinfohelper.py:store_build_package_information.
* the package detail view retrieves license-for-package objects
I take this approach instead of adding
License{id, name, path} and license-package {id, foreign key package_id,
foreign key license_id}
because license.path clearly depends on package.
For (2) provide workaround helper functions in the model Package class...
* leave the database package.license set to the bb LICENSE values,
* add the get_license_data() to the model, Package class as a method, but I'm
not sure that all of the data is available post-build. I am sure that the
tmp/deploy/licenses/$PN could be calculated and discovered. I'm not sure that
the association between paths and files could easily be made post-build time.
Comments?
Dave Lerner
_______________________________________________
toaster mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/toaster
