[Yum-devel] foreign arch's and introduction

Ken MacLeod ken at bitsko.slc.ut.us
Fri Jul 28 17:52:18 UTC 2006


I'm new to the list so I thought I'd introduce myself before launching
into discussion.  I'm relatively new to Yum, Fedora, Mock, Plague,
etc. but I've been building tons of RPMs since the late 90's, mostly
for work-related devel and admin, and up til now have been using our
own apt repositories.  In my current project, we're building packages
and filesystems for embedded systems and our development hosts.  I've
set up Yum, Plague, and Mock for building native host RPMs and now I'm
headed in the direction of adding support for building target
filesystems and cross-building RPMs with Mock and Plague.  This email
is to give a heads up on where I'm going and give a context for
patches or plugins to come.

With a little prototyping, it looks like I only need to do two things
with Yum to build target filesystems and cross-tools directories.

Both of these are done entirely with --installroot and a
target-specific yum.conf/repos, very much like Mock.

I'll start with the cross-tools directories because I think that'll be
easily done with a plug-in.  A "cross-tool directory" is a
target-specific tree that contains the cross-compiler toolchain that
runs natively on the host but compile for the target.  Separate rooted
directories are necessary (rather than a packaging policy for
installing in /) to allow for multiple target releases for development
on the same host.  Since the cross-tools are "native" but the
--installroot only has the tool RPMs, dependencies have to be resolved
from the real root RPMDB.  AFAICT, that should be easy to do in a
plug-in.

The target filesystems are a little trickier because Yum has a
built-in assumption that RPMs to be installed are "native", ie. the
same arch as this host.  I'll need to add support in yum/depsolve.py,
yum/config.py, and yum/__init__.py to allow an override of the "this
arch" (currently coming from rpmUtils' getCanonArch, getBaseArch,
et. al).

Two approaches I considered were to scan the RPMs in the repos for
their architecture or have a yum.conf or .repo config that specify
their architecture.  Both of these are less than desirable because
repositories simply can have multiple architectures and Yum does the
right thing (selecting only RPMs in the arch list).

The approach I've settled on is to add --arch= and --arch-list=
options to specify the arch of the --installroot.  --arch and
--arch-list would only be allowed with --installroot.  --arch sets the
base arch and allows the arch-list to be created from rpmUtils'
getArchList.  --arch-list overrides that.

As far as a patch to Yum for architecture options support, I'm
thinking the right approach is to allow "config" plug-ins to set the
architecture options.  Then, I'll have a plug-in for foreign arch
target filesystem support.

Looking further ahead, which are topics for other mailing lists, I'll
be extending Mock to support creating a target devel filesystem (for
satisfying Requires), matching BuildRequires dependencies to either
the target or the chroot host filesystem, and installing the
cross-tools.  Plague would then have target arch in addition to host
arch.  I'd also like Plague to build for multiple releases in one job.

Ideas and suggestions welcome,

  -- Ken



More information about the Yum-devel mailing list