[Toaster] More Toaster implementation questions...

[Barros Pena, Belen]

On 07/01/2014 17:39, "Lerner, Dave" <dave.lerner at windriver.com> wrote:

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

Well spotted :) There is an issue in Bugzilla for this:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=5648

You will find more cases like this as you start working on features. I
guess a generic approach we can follow is not displaying the information
in the front end until the necessary back end changes have been made. In
the case of the license file information for packages, we can build the
page without it and add it whenever it becomes available.

But we'll probably make decisions on a case by case basis, so when you
find situations where the back end does not provide the information
required by the front end specification, bring them up on the mailing list
to discuss.

Thanks!

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