| Summary: | Incorrect number of packages built in image dashboard (for clean builds only) | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] Toaster | Reporter: | Belen Barros Pena <belen.barros.pena> |
| Component: | toaster | Assignee: | Farrell Wymore <farrell.wymore> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium | CC: | alexandru.damian, belen.barros.pena, cristiana.voicu, david.reyna, jessica.zhang, srifenbark, Yuan.Sun2 |
| Version: | unspecified | ||
| Target Milestone: | 1.6 M5 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | 09 April 2014: Set documentation flag to "No." | ||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
|
Description
Belen Barros Pena
2014-04-01 09:43:26 UTC
These numbers do indeed appear to be inconsistent but i'm not sure where the problem is. Here is a summary: 1) On the dashboard page, 'Packages included' is exactly the number of rows in the target_installed_packages table for a single target. In my example, this number is 29. 2) Again on the dashboard page, 'Packages built' is exactly the number or rows in the package table for a single build. In my example, this number is 6146. 3) The Packages page for this build indicates 3686 packages in my example. Looking at the package table in the database, there are 2460 packages with no installed_name, size is -1, installed_size of 0, no version, no license, no description. These entries do have names and ids. So its clear where the package page (paginator) is getting it's number: 6146 - 2460 = 3686; by ignoring the anomalous package entries. So the question is: should the computation of 'Packages built' not include these anomalous package entries? Should the package page (paginator) include the anomalous entries? Or, should the anomalous entries be in the db at all? (In reply to comment #1) > These numbers do indeed appear to be inconsistent but i'm not sure where the > problem is. Here is a summary: > > 1) On the dashboard page, 'Packages included' is exactly the number of rows > in the target_installed_packages table for a single target. In my example, > this number is 29. > 2) Again on the dashboard page, 'Packages built' is exactly the number or > rows in the package table for a single build. In my example, this number is > 6146. > 3) The Packages page for this build indicates 3686 packages in my example. > > Looking at the package table in the database, there are 2460 packages with > no installed_name, size is -1, installed_size of 0, no version, no license, > no description. These entries do have names and ids. So its clear where the > package page (paginator) is getting it's number: 6146 - 2460 = 3686; by > ignoring the anomalous package entries. > > So the question is: should the computation of 'Packages built' not include > these anomalous package entries? The answer is no, the 'Packages built' computation should not include the anomalous package entries. The anomalous package entries correspond to packages that are not built: the entries exist only in order to be able to provide the full dependency chain. Without them, the dependency information in Toaster would be incomplete. Should the package page (paginator) include > the anomalous entries? No, same reason as above. > Or, should the anomalous entries be in the db at all? Yes, we do need them: without them, we would have incomplete dependency information. Although we might argue if the packages table is the right place to store them, but that's a different issue :) The number of packages built in the image dashboard has to be calculated in the same way as in the built packages table (i.e. excluding packages not built recorded only for dependency information purposes). I hope this explains commit 10297261219d4373843b31e8aaaed094fcbcf605 This bug had no impact to docs. Setting to "No." Scott Verified in 046a9ea30356daf4f3f8f4ddfc5b57fcfd85a27f. |