[Yum-devel] [PATCH] yum: install foreign arch

Ken MacLeod ken at bitsko.slc.ut.us
Wed Aug 2 15:29:43 UTC 2006


skvidal at linux.duke.edu (seth vidal) writes:

> On Tue, 2006-08-01 at 19:03 -0500, Ken MacLeod wrote:
> > I posted more details earlier[1], but the use case is to create
> > [embedded] target filesystems on build systems for
> > cross-development.
> > 
> > In this case, it's well understood that scriptlets (if any) don't
> > run when installing the target filesystem.  All necessary
> > post-install is done separately.
> 
> I'm not comfortable including a patch that will knowingly create
> broken installs.

I've worked in environments and shared experiences with others enough
that I absolutely share your concern.  I'm willing to do what is
necessary to make sure this is intended for the right context.

Context is the key here.

For about two years we've been building target filesystems from RPMS
from three commercial distributions and our own "from scratch"
distribution.

There are no scripts in the RPMs we create or from two of the vendors.
The other vendor has very few scripts (ie. 15 out of 750 RPMs for a
particular target) and are only run in the case where you log in and
install an RPM into a live filesystem.  Those scripts are restricted
to helper functions like configuring init.d and the shell, which are
parsable and can be emulated when doing a build-host target filesystem
install.  Just in case, we do review new releases and would expect
others to as well.

In summary: packaging policy in these distributions assumes very
restricted scriptlets or none.

We've automated the builds of all of our RPMs, but we're getting to
the point where we need tools like Plague, Mock, and Yum.  We'd like
to suggest these tools to a couple of our vendors, and they'll
certainly help community embedded projects.

Here's what I'm suggesting in more detail,

  I rework the patch I sent so that it only centralizes the arch
  information on YumBase (rather than having various callers call
  rpmUtils.arch directly to get "current arch" info; calls to
  rpmUtils.arch that take an arch argument are OK).

  I add a ConfigPluginConduit.setArch(arch) method.

This assumes the user must install a plugin to get the ability to
override the arch.  Only the plugin will have the --arch option.  If
the plugin is associated with cross-development tools, it pretty much
sets the context of when this capability is used.  While this opens
the door to other plugins setting the arch, those authors pretty much
still need to go through a similar "should I do this?" thought process
and we can document setArch accordingly.


Note, right now I'm interested in developing the right
policy/guideline going forward.  Since embedded developers use more
architectures than other systems, and once we've determined the right
policy/approach, there will be more patches that round out the
architecture support.  I say that now because I'd like to work with
the current development tree, without giving any surprises, than to
keep everything in a separate branch that will be less tested and
require a bigger merge later.

Thanks,

  -- Ken



More information about the Yum-devel mailing list