TipsAndTricks/EnablingAPackageFeed: Difference between revisions

From Yocto Project
Jump to navigationJump to search
No edit summary
Line 116: Line 116:
** make a dir for repos
** make a dir for repos
*** <pre> mkdir -p /etc/yum.repos.d </pre>
*** <pre> mkdir -p /etc/yum.repos.d </pre>
** add the repo  
** add the repo. The file name <strong> must </strong> end in '.repo' for instance  mybuild.repo
  <pre>  
  <pre>  
   [myrepo]                                                                                                                                             
   [myrepo]                                                                                                                                             

Revision as of 19:58, 27 June 2017

Caveat

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: all core2_32 edison

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 http://my-server.com/repo

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
rsync -r -u --exclude 'x86_64*' tmp/deploy/rpm/* /var/www/html/repo

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

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

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
      •  mkdir -p /etc/yum.repos.d 
    • add the repo. The file name must end in '.repo' for instance mybuild.repo
 
  [myrepo]                                                                                                                                             
  name=myRepo for testing                                                                                                                         
  baseurl=http://<host ip addr or hostname>:5678                      
  enabled=1                                               
  metadata_expire=0                            
  gpgcheck=0                       
  
  • install something
 dnf -v install mdadm
 

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

Future Work

  • httpd
  • feed-stability