package summary now ready for review

package summary now ready for review

[Reyna, David]

[-- Attachment #1: Type: text/plain, Size: 1826 bytes --]

Hi Alex and Belen,

I have implemented the updated Package Summary page, using what I learned from the Recipe Summary page, and it can be found at "dreyna/package-summary-view".

  http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit?h=dreyna%2Fpackage-summary-view

I have a few questions and observations.

1) The design document did not define the case where there is no recipe link in the package record.

In this implementation, I followed the previous page's example and kept those package entries in the table, but set the recipe-related entries to blank when there was no recipe defined.

It may be your intent to skip all packages that do not have recipes. If so, I can easily make that change.

BTW, a nasty consequence of including packages with no recipes is that when you sort on a recipe-related column, you end up with several pages of blank values before you get to real data.

2) Why does the package class have members for "section" and "license"? Specifically, is there ever a case when the package's license and section values do not equal the attached recipe license values?

It would seem to me that these two values are redundant, and the respective recipe values should be used instead. It may be that the intent is for these values to be available when there is no recipe attached, but in my test the license value (at least) is always empty when there is no recipe, so no gain.

In this implementation I used the package's version of "license", but if you do decide to factor it out I can make my change easily.

3) I will note in passing that the design document does not have the column help text that the sample page from "yoctoproject.org/toaster/all-packages.html" has, so we may want to update that document for the benefit of the testers.

Thanks,
David



[-- Attachment #2: Type: text/html, Size: 2815 bytes --]

Re: package summary now ready for review

[Barros Pena, Belen]

On 07/02/2014 06:29, "Reyna, David" <david.reyna@windriver.com> wrote:

>Hi Alex and Belen,
> 
>I have implemented the updated Package Summary page, using what I learned
>from the Recipe Summary page, and it can be found at
>³dreyna/package-summary-view².
>
> 
>  
>http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit?h=dreyna%2Fp
>ackage-summary-view
><http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit?h=dreyna%2F
>package-summary-view>

Thanks, David! I will be looking at this today.

> 
>I have a few questions and observations.
> 
>1) The design document did not define the case where there is no recipe
>link in the package record.
>
> 
>In this implementation, I followed the previous page¹s example and kept
>those package entries in the table, but set the recipe-related entries to
>blank when there was no recipe defined.
> 
>It may be your intent to skip all packages that do not have recipes. If
>so, I can easily make that change.
> 
>BTW, a nasty consequence of including packages with no recipes is that
>when you sort on a recipe-related column, you end up with several pages
>of blank values before you get to real data.

As far as I know, any packages that have been built during the selected
build should have a recipe. If a package has no recipe, that means it has
not being built during the selected build, but an entry in the orm_package
table might exist for dependency tracking purposes (in particular for
RRECOMMENDS, RPROVIDES, RSUGGESTS, RREPLACES and RCONFLICTS). Alex, if
this is not correct, please let me know.

Packages without recipe should not show in the built packages table (or
package summary, as you call it).

> 
>2) Why does the package class have members for ³section² and ³license²?
>Specifically, is there ever a case when the package¹s license and section
>values do not equal the attached recipe license values?

I believe those will never be different to the recipe values, but not all
recipe values might apply to a certain package. Once again, I could be
wrong. Paul Eggleton is probably the person who can explain this best.

> 
>It would seem to me that these two values are redundant, and the
>respective recipe values should be used instead. It may be that the
>intent is for these values to be available when there is no recipe
>attached, but in my test the license value (at least)
> is always empty when there is no recipe, so no gain.
> 
>In this implementation I used the package¹s version of ³license²,

I think this is the right thing to do, but once again Alex | Paul will be
able to confirm.

> but if you do decide to factor it out I can make my change easily.
> 
>3) I will note in passing that the design document does not have the
>column help text that the sample page from
>³yoctoproject.org/toaster/all-packages.html² has, so we may want to
>update that document for the benefit of the testers.

I am really sorry, but we'll need to make do with the prototype. Producing
all encompassing, always up-to-date documentation is a full time job. If I
did that, I would be doing nothing else :(

I really hope that's ok. If the testers have any questions, please tell
them to contact me. I think we should probably work quite closely and be
in touch anyway.

Cheers

Belén

> 
>Thanks,
>David
> 
> 

Re: package summary now ready for review

[Paul Eggleton]

On Friday 07 February 2014 15:30:41 Barros Pena, Belen wrote:
> On 07/02/2014 06:29, "Reyna, David" <david.reyna@windriver.com> wrote:
> >1) The design document did not define the case where there is no recipe
> >link in the package record.
> >
> >In this implementation, I followed the previous page¹s example and kept
> >those package entries in the table, but set the recipe-related entries to
> >blank when there was no recipe defined.
> >
> >It may be your intent to skip all packages that do not have recipes. If
> >so, I can easily make that change.
> >
> >BTW, a nasty consequence of including packages with no recipes is that
> >when you sort on a recipe-related column, you end up with several pages
> >of blank values before you get to real data.
> 
> As far as I know, any packages that have been built during the selected
> build should have a recipe. If a package has no recipe, that means it has
> not being built during the selected build, but an entry in the orm_package
> table might exist for dependency tracking purposes (in particular for
> RRECOMMENDS, RPROVIDES, RSUGGESTS, RREPLACES and RCONFLICTS). Alex, if
> this is not correct, please let me know.
> 
> Packages without recipe should not show in the built packages table (or
> package summary, as you call it).

Unless we're talking about binary packages added through some post-processing 
at the end of creating the image (possible, but unlikely I would think) 
packages *must* have a recipe. If they do not currently, we have a bug. Where 
are these packages coming from?

> >2) Why does the package class have members for ³section² and ³license²?
> >Specifically, is there ever a case when the package¹s license and section
> >values do not equal the attached recipe license values?
> 
> I believe those will never be different to the recipe values, but not all
> recipe values might apply to a certain package. Once again, I could be
> wrong. Paul Eggleton is probably the person who can explain this best.

Per-package licensing is both possible and used within the core metadata - 
sometimes the content licensing is split along package lines, e.g. from the 
libtasn1 recipe in OE-Core:

LICENSE = "GPLv3+ & LGPLv2.1+"
LICENSE_${PN}-bin = "GPLv3+"
LICENSE_${PN} = "LGPLv2.1+"

As for SECTION, well, SECTION is set rather poorly in the metadata anyway; 
it's conceivable it might be different on a per-package basis but unless we go 
on a crusade of setting this variable I doubt it ever will be. That said, what 
is the cost to implementing it?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: package summary now ready for review

[Barros Pena, Belen]

On 07/02/2014 06:29, "Reyna, David" <david.reyna@windriver.com> wrote:

>Hi Alex and Belen,
> 
>I have implemented the updated Package Summary page, using what I learned
>from the Recipe Summary page, and it can be found at
>³dreyna/package-summary-view².
>
> 
>  
>http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit?h=dreyna%2Fp
>ackage-summary-view
><http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit?h=dreyna%2F
>package-summary-view>

Hi David,

This is looking great. I have only found 2 issues:

* When the search returns no results, there is a sentence before the table
headings saying "No packages were recorded for this target!". We need to
remove it.

* When displaying search results, the page heading should update to  show
the number of search results returned. You can see it working in the
builds table.

We also need to work out what's happening with those packages that have no
recipe (or any other information for that matter).

Cheers

Belén


> 
>I have a few questions and observations.
> 
>1) The design document did not define the case where there is no recipe
>link in the package record.
>
> 
>In this implementation, I followed the previous page¹s example and kept
>those package entries in the table, but set the recipe-related entries to
>blank when there was no recipe defined.
> 
>It may be your intent to skip all packages that do not have recipes. If
>so, I can easily make that change.
> 
>BTW, a nasty consequence of including packages with no recipes is that
>when you sort on a recipe-related column, you end up with several pages
>of blank values before you get to real data.
> 
>2) Why does the package class have members for ³section² and ³license²?
>Specifically, is there ever a case when the package¹s license and section
>values do not equal the attached recipe license values?
> 
>It would seem to me that these two values are redundant, and the
>respective recipe values should be used instead. It may be that the
>intent is for these values to be available when there is no recipe
>attached, but in my test the license value (at least)
> is always empty when there is no recipe, so no gain.
> 
>In this implementation I used the package¹s version of ³license², but if
>you do decide to factor it out I can make my change easily.
> 
>3) I will note in passing that the design document does not have the
>column help text that the sample page from
>³yoctoproject.org/toaster/all-packages.html² has, so we may want to
>update that document for the benefit of the testers.
> 
>Thanks,
>David
> 
> 

Re: package summary now ready for review

[Barros Pena, Belen]

On 07/02/2014 16:11, "Paul Eggleton" <paul.eggleton@linux.intel.com> wrote:

>On Friday 07 February 2014 15:30:41 Barros Pena, Belen wrote:
>> On 07/02/2014 06:29, "Reyna, David" <david.reyna@windriver.com> wrote:
>> >1) The design document did not define the case where there is no recipe
>> >link in the package record.
>> >
>> >In this implementation, I followed the previous page¹s example and kept
>> >those package entries in the table, but set the recipe-related entries
>>to
>> >blank when there was no recipe defined.
>> >
>> >It may be your intent to skip all packages that do not have recipes. If
>> >so, I can easily make that change.
>> >
>> >BTW, a nasty consequence of including packages with no recipes is that
>> >when you sort on a recipe-related column, you end up with several pages
>> >of blank values before you get to real data.
>> 
>> As far as I know, any packages that have been built during the selected
>> build should have a recipe. If a package has no recipe, that means it
>>has
>> not being built during the selected build, but an entry in the
>>orm_package
>> table might exist for dependency tracking purposes (in particular for
>> RRECOMMENDS, RPROVIDES, RSUGGESTS, RREPLACES and RCONFLICTS). Alex, if
>> this is not correct, please let me know.
>> 
>> Packages without recipe should not show in the built packages table (or
>> package summary, as you call it).
>
>Unless we're talking about binary packages added through some
>post-processing 
>at the end of creating the image (possible, but unlikely I would think)
>packages *must* have a recipe. If they do not currently, we have a bug.
>Where 
>are these packages coming from?

So it seems that those packages are there in order to record the full
dependency chain. It also seems clear that they should not be shown in the
built packages table. The question is: how do we filter them out? Alex and
Paul have suggested to flag them in the database in order to identify them
(and filter them out) easily. I have opened a Bugzilla entry for this and
assigned it to Alex:

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

Cheers

Belén


>
>> >2) Why does the package class have members for ³section² and ³license²?
>> >Specifically, is there ever a case when the package¹s license and
>>section
>> >values do not equal the attached recipe license values?
>> 
>> I believe those will never be different to the recipe values, but not
>>all
>> recipe values might apply to a certain package. Once again, I could be
>> wrong. Paul Eggleton is probably the person who can explain this best.
>
>Per-package licensing is both possible and used within the core metadata
>- 
>sometimes the content licensing is split along package lines, e.g. from
>the 
>libtasn1 recipe in OE-Core:
>
>LICENSE = "GPLv3+ & LGPLv2.1+"
>LICENSE_${PN}-bin = "GPLv3+"
>LICENSE_${PN} = "LGPLv2.1+"
>
>As for SECTION, well, SECTION is set rather poorly in the metadata
>anyway; 
>it's conceivable it might be different on a per-package basis but unless
>we go 
>on a crusade of setting this variable I doubt it ever will be. That said,
>what 
>is the cost to implementing it?
>
>Cheers,
>Paul
>
>-- 
>
>Paul Eggleton
>Intel Open Source Technology Centre