[Toaster] More Toaster implementation questions...

[Lerner, Dave]

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