Download Word - JIRA

[GDP-223] Evaluation of smart as package manager for GDP Created: 30/May/16
Updated:
23/Dec/16 Resolved: 15/Jun/16
Status:
Project:
Component/s:
Affects
Version/s:
Fix Version/s:
Done
GENIVI Development Platform
None
None
Type:
Reporter:
Resolution:
Labels:
Remaining
Estimate:
Time Spent:
Original
Estimate:
Task
Priority:
Agustin Benito Bethencourt Assignee:
Done
Votes:
gdp, gdp_master
Not Specified
Epic Link:
Epic Link:
GDP Master
GDP Master
None
Low
Agustin Benito Bethencourt
0
Not Specified
Not Specified
Description
Background
Smart was developed originally by Gustavo Niemeyer, from Canonical.




About Gustavo: https://github.com/niemeyer and https://twitter.com/gniemeyer
Web: https://labix.org/smart
PjM: https://launchpad.net/smart
Wikipedia article about smart.
Other interesting links:



Decision about dropping zypper and using smart by the Yocto project.
Last release by Gustavo: smart 1.4.1
White paper from Intel about smart.
Task description
This task track the analysis effort to evaluate smart as a package manager for GDP. Follow up
the discussion on the genivi-projects ML
Deliverables
Should we use it or not?
We will not use smart. We will simply stay with RPM in IMAGE_FEATURES.
Comments
Comment by Agustin Benito Bethencourt [ 30/May/16 ]
Two references that reflect the state of smart within Yocto:


Important Bug 9675 from Yocto. This bug is a target in the recent bug triage.
A Smart Way to Manage Packages in Yocto Project - Teppei Asaba, Fujitsu. Video from
the talk about Smart I attended to at ELC 2016.
o From Min 18:00 he explains that there is no significant community activity since
2012 together with several important problems to face in the solution.
o Min 21:00 he provides a practical example.
o Min 28:50 next steps Fujitsu is working on
o Min 30:45 he recognises that license checking patch sent by Fujitsu has not been
reviewed. He proposes to revamp the community.
o Min 40:40 Q&A: Yocto dev recognises smart has not "received much love".
 The patch was reviewed during ELC
 Teppei confirms Fujitsu will keep working on smart.
Comment by Agustin Benito Bethencourt [ 30/May/16 ]
Sent mail to the projects mailing list pointing here to track the discusiion.
Comment by Sanjeev BA [ 30/May/16 ]
I think we also used this in our Tizen Raspberry Pi porting effort.
Please check.
https://blogs.s-osg.org/rpi2-getting-smart-tizen/
https://wiki.tizen.org/wiki/Runtime_package_management_in_Tizen_on_Yocto_with_Smart
Comment by Rudolf Streif [ 31/May/16 ]
This topic was discussed during the PMO call on Tuesday 5/31.
The GDP environment is somewhat different from a typical Linux distribution environment in
the sense that a GDP image as such already includes all components that its build system
creates. For a typical Linux distro, a basic images are created e.g. workstation, server, etc. that
provide a core system. Users can then use the package management system to download and
install thousands of other packages from repositories. Currently we do not have a package
repository for GDP pretty much also because everything we build is already included with the
GDP image. That does however not mean that we could not have it though.
In this discussion we also need to distinguish:


Platform Package Manager (PPM): installs, updates, removes etc. packages from files
and maintains the package database. The typical examples are RPM, DEB, IPK.
Package Downloader (PD): checks a download server for new packages that apply to the
system, downloads them and then defers to the platform package manager for
installation (either by calling the respective executables or using libraries). Typical
examples are apt-get, dnf, yum, zypper and Smart PM
The PPM for GDP currently is RPM (basically because the YP/OE default is RPM). However, it
is not included with GDP. Eventually, the PD for GDP should become SOTA for which we are
currently setting up the server-side infrastructure. That will grow GDP into an end-to-end
platform.
Therefore my suggestion is to



Include the PPM into the GDP (add package-management to IMAGE_FEATURES)
Include SOTA with GDP
Set up SOTA server-side infrastructure
If there is functionality missing in SOTA then it would make more sense to add that
functionality to SOTA rather than use another system. For example, SOTA may typically push
update notifications to the clients but adding functionality for a client to query the SOTA server
for updates is not that hard to add.
Comment by Jonathan Maw [ 07/Jun/16 ]
package-management should already be in IMAGE_FEATURES, inherited from meta-ivi's iviimage.inc.
rpm exists on the target hardware, though if there are more comprehensive tests that packagemanagement is installed, I'd like to try those, as well.
Comment by Agustin Benito Bethencourt [ 07/Jun/16 ]
Just for tracking purposes, there is a PR to drop ipk that is, support RPM only.
Comment by Jeremiah Foster [ 07/Jun/16 ]
Can we include rpm packages on an eventual target image? Don't they have dependencies on
GPLv3 components, like cpio?
Comment by Agustin Benito Bethencourt [ 15/Jun/16 ]
Based on the license policy, we can if the code is not meant to be used in production.
Generated at Fri May 05 19:12:23 PDT 2017 using JIRA 7.0.0#70107sha1:6cd5e8da0433ba37cd68ac1f1a6078fc22964e15.