|
|
| (4 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| == Caveat ==
| | This is now covered in the [https://docs.yoctoproject.org/dev-manual/common-tasks.html#using-runtime-package-management documentation]. |
| This article is based on work done a few years ago with fido (1.8) and only covers using smart with rpm. Needs some testing and extended to cover using dnf. | |
| | |
| Instructions assume you have had at least one successful build of your target image.
| |
| | |
| == Select Your Package Format ==
| |
| package format is set via variable PACKAGE_CLASSES, typically in local.conf. Look for line like
| |
| PACKAGE_CLASSES ?= "package_rpm"
| |
| This means you're using rpm.
| |
| | |
| == Know Your Package Architectures ==
| |
| Your OS image will be comprised of a number of different package architectures.
| |
| === From the build system view ===
| |
| The package feed needs to know what they are so look in tmp/deploy/rpm
| |
| $ ls tmp/deploy/rpm/
| |
| all core2_32 edison x86_64_nativesdk
| |
| You can exclude anything starting with x86_64. This means the architectures on the target are: <tt>all core2_32 edison</tt>
| |
| === From target system view ===
| |
| $ rpm -qq
| |
| look at the endings of the various packages. For example , if you build for qemux86-64 the suffixes will be
| |
| core2_64
| |
| qemux86_64
| |
| all
| |
| so those are the architectures supported on the target.
| |
| | |
| == Select Your Package Feed URL ==
| |
| Is this example we'll use <tt>http://my-server.com/repo</tt>
| |
| | |
| == Add Package Manager to Build ==
| |
| Smart package manager is in oe-core, so there is no need to add any extra layers. You do, however need to tell the build system to include pkg management on the target, since excluding package management saves space, it is not enabled by default.
| |
| | |
| EXTRA_IMAGE_FEATURES += " package-management "
| |
| | |
| On releases prior to jethro, you *may* need to also do
| |
| IMAGE_INSTALL_append=" python-smartrpm "
| |
| | |
| == Configure Package Feed in Build ==
| |
| Now you have the information to create a package feed, ideally you add details in your distro conf file. If you are not using your own distro, you can set the following in local.conf. Note, if you only want to configure your channels on the target and not have any defaults, these definitions can be excluded.
| |
| PACKAGE_FEED_URIS = "http://my-server.com/repo"
| |
| PACKAGE_FEED_BASE_PATHS = "rpm"
| |
| PACKAGE_FEED_ARCHS = "all edison core2_32"
| |
| | |
| == Create Package Feed ==
| |
| * Re-build image so it includes smart and the package feed info
| |
| ** Also, if you find you need an additional recipe not included in the image e.g. gawk, you can do bitbake gawk and it's packages will be available too.
| |
| *** this can be done iteratively
| |
| * Update repo package indices
| |
| bitbake package-index
| |
| * Copy packages to server. This sample script assumes files are served from /var/www/html/repo
| |
| ** We exclude x86_64 as those are host side (aka native) rpms
| |
| <pre>
| |
| rsync -r -u --exclude 'x86_64*' tmp/deploy/rpm/* /var/www/html/repo
| |
| </pre>
| |
| | |
| == Run Package Manager on Target ==
| |
| * Make sure network is up and sync with package feed.
| |
| smart update
| |
| * Install my-package
| |
| smart search my-package
| |
| smart install my-package
| |
| | |
| == Recover Package Feed Config On Target ==
| |
| Smart does not have a config file, so config must be done via command line. This script re-creates the config set by distro in example above
| |
| <pre>
| |
| feed_url="http://my-server.com/repo"
| |
| platform="my-platform"
| |
| repo_name="my-repo"
| |
| for arch in all edison core2_32; do
| |
| smart channel --add $platform-$arch type=rpm-md name="$repo_name" baseurl=$feed_url/$arch -y
| |
| done
| |
| </pre>
| |
| Rebuild the cache with the new channels added
| |
| $ smart update
| |
| This will result in a set of feeds you can see with
| |
| $ smart channel --show
| |
| | |
| == Quick and Dirty Feed Serving ==
| |
| If you don't have a web server already serving up a directory and don't feel like going through the effort to do that you can do the following.
| |
| * Assume your feed is /opt/feed
| |
| * apt-get/dnf install python-twistd
| |
| * run twistd on the directory
| |
| $ twistd -n web --path /opt/feed -p 5678
| |
| * This way you can serve diff feeds on diff ports easily
| |
| | |
| == Make an RPM Package feed for Pyro and greater releases ==
| |
| === From a Build dir ===
| |
| ==== Easiest Way ====
| |
| * Use RPMS
| |
| ** PACKAGE_CLASSES = "package_rpm" in local.conf
| |
| * have package tools
| |
| ** EXTRA_IMAGE_FEATURES += " package-management " in local.conf
| |
| * build something you want
| |
| ** bitbake mdadm
| |
| * update the package indices
| |
| ** bitbake package-index
| |
| * Serve up feed
| |
| ** twistd -n web --path tmp/deply/rpm -p 5678
| |
| ==== How to keep a separate feed Dir ====
| |
| * Use RPMS
| |
| ** PACKAGE_CLASSES = "package_rpm" in local.conf
| |
| * have package tools
| |
| ** EXTRA_IMAGE_FEATURES += " package-management " in local.conf
| |
| * build something you want
| |
| ** bitbake mdadm
| |
| * copy to dir
| |
| ** rsync -r -u --exclude 'x86_64*' tmp/deploy/rpm/* feedDir/
| |
| * Build the tools needed to make directories into repos
| |
| ** bitbake createrepo-c-native -caddto_recipe_sysroot
| |
| * Turn the directory into a repo
| |
| ** oe-run-native createrepo-c-native createrepo_c feedDir
| |
| * Serve up feed
| |
| ** twistd -n web --path feedDir -p 5678
| |
| | |
| === From the Target ===
| |
| * make the target aware of the repo you just created.
| |
| ** make a dir for repos
| |
| *** <pre> mkdir -p /etc/yum.repos.d </pre>
| |
| ** add the repo. The file name <strong> must </strong> end in '.repo' for instance mybuild.repo
| |
| <pre>
| |
| [myrepo]
| |
| name=myRepo for testing
| |
| baseurl=http://<host ip addr or hostname>:5678
| |
| enabled=1
| |
| metadata_expire=0
| |
| gpgcheck=0
| |
| </pre>
| |
| * install something
| |
| <pre>
| |
| dnf -v install mdadm
| |
| </pre>
| |
| | |
| === Why Might I Use This? ===
| |
| This workflow is one where you need to iteratively try out what packages you want on your image. In my case, I was doing a native build of a complex sw repo and needed to make;fail;add dependency somehow;make again; quite a few times. I certainly did not want to wait while bitbake made a new image with my additional dependency and then wait again while dd copied that image to my usb key. This way, I could bitbake dependency, rerun createrepo, dnf install from target. Much much faster.
| |
| | |
| | |
| == Further Reading ==
| |
| * [http://labix.org/smart/user-guide Smart online user guide]
| |
| * [https://www.fujitsu.com/jp/group/fct/documents/events/2016/A_Smart_Way_to_Manage_Packages_in_Yocto_Project.pdf Fujitsu ELC 2016 Presentation]
| |
| | |
| == Future Work ==
| |
| * httpd
| |
| * feed-stability
| |
