Uploaded image for project: 'GENIVI Development Platform'
  1. GENIVI Development Platform
  2. GDP-223

Evaluation of smart as package manager for GDP

    Details

    • Type: Task
    • Status: Done
    • Priority: Low
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:

      Description

      Background

      Smart was developed originally by Gustavo Niemeyer, from Canonical.

      Other interesting links:

      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.

        Attachments

          Issue Links

            Activity

            Hide
            toscalix Agustin Benito Bethencourt added a comment -

            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.
              • 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.
              • Min 21:00 he provides a practical example.
              • Min 28:50 next steps Fujitsu is working on
              • Min 30:45 he recognises that license checking patch sent by Fujitsu has not been reviewed. He proposes to revamp the community.
              • 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.
            Show
            toscalix Agustin Benito Bethencourt added a comment - 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. 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. Min 21:00 he provides a practical example. Min 28:50 next steps Fujitsu is working on Min 30:45 he recognises that license checking patch sent by Fujitsu has not been reviewed. He proposes to revamp the community. 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.
            Hide
            toscalix Agustin Benito Bethencourt added a comment -

            Sent mail to the projects mailing list pointing here to track the discusiion.

            Show
            toscalix Agustin Benito Bethencourt added a comment - Sent mail to the projects mailing list pointing here to track the discusiion.
            Hide
            sanjeev Sanjeev BA added a comment - - edited
            Show
            sanjeev Sanjeev BA added a comment - - edited 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
            Hide
            rudolf.streif Rudolf Streif added a comment -

            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.

            Show
            rudolf.streif Rudolf Streif added a comment - 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.
            Hide
            jonathanmaw Jonathan Maw added a comment -

            package-management should already be in IMAGE_FEATURES, inherited from meta-ivi's ivi-image.inc.
            rpm exists on the target hardware, though if there are more comprehensive tests that package-management is installed, I'd like to try those, as well.

            Show
            jonathanmaw Jonathan Maw added a comment - package-management should already be in IMAGE_FEATURES, inherited from meta-ivi's ivi-image.inc. rpm exists on the target hardware, though if there are more comprehensive tests that package-management is installed, I'd like to try those, as well.
            Hide
            toscalix Agustin Benito Bethencourt added a comment -

            Just for tracking purposes, there is a PR to drop ipk that is, support RPM only.

            Show
            toscalix Agustin Benito Bethencourt added a comment - Just for tracking purposes, there is a PR to drop ipk that is, support RPM only.
            Hide
            jeremiah.foster Jeremiah Foster added a comment -

            Can we include rpm packages on an eventual target image? Don't they have dependencies on GPLv3 components, like cpio?

            Show
            jeremiah.foster Jeremiah Foster added a comment - Can we include rpm packages on an eventual target image? Don't they have dependencies on GPLv3 components, like cpio?
            Hide
            toscalix Agustin Benito Bethencourt added a comment -

            Based on the license policy, we can if the code is not meant to be used in production.

            Show
            toscalix Agustin Benito Bethencourt added a comment - Based on the license policy, we can if the code is not meant to be used in production.

              People

              • Assignee:
                toscalix Agustin Benito Bethencourt
                Reporter:
                toscalix Agustin Benito Bethencourt
              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: