Re: Bootstrapping an RPM area.

[Tim Mooney <mooney dogbert cc ndsu NoDak edu>]

In regard to: Bootstrapping an RPM area., Steve Juranich said (at 1:19pm on...:

> I've done a little experimentation in a sandbox and I've come up with what I
> think is an acceptable way of doing things, but I'd like to know if there
> is a "right" way.

Why don't you outline your method, and we'll shoot holes in it (if need
be)?  ;-)

I've never attempted to build RPM on OS X, but I certainly have on other
platforms over the years, most recently rpm-4.4.6 on Solaris 8 and Solaris
10.  It won't build out of the box (especially if you're not using gcc),
but it's not terribly difficult to get it built.  I have a few minor
patches that help with that, and I'll be submitting them upstream once
my Solaris 8 build box is back online.

There are quite a few prerequisites, some of which aren't strictly
required.  Nearly all of the prerequisites build pretty easily, though,
so they're not much of a barrier.

If you proceed with rpm 4.4.6 or one of the development snapshots of what
will be 4.4.7 you'll probably encounter a couple problems on Solaris,
once you get the software built:

- for reasons I haven't investigated yet, the built-in dependency
  generator doesn't generate requires or provides information for either
  executables or shared objects.  Switching back to the older script-based
  method works, but the scripts that ship with RPM 4.4.6 don't distinguish
  between ELF32 and ELF64.  That's pretty easy to fix, if you're so
  inclined.  Once I have my patches for the other issues submitted
  upstream, I intend to come back to this one and see if I can determine
  what the problem is.  Since I have a workaround, it's lower priority
  right now.

- if you install RPM anywhere other than the default location, your
  RPM "magic" file (for file type identification) will end up under
  your $prefix , but build/rpmfc.c hardcodes the location of the magic
  file to be /usr/lib/rpm/magic.  That actually causes RPM to core dump
  when it gets to the packaging part of the build.  If you fix the path in
  the source or install a symlink to where your rpm/magic file is, that
  problem goes away.

- also for reasons I haven't investigated, my %post scripts all fail with
  messages similar to

		/var/tmp/rpm-tmp.24704: /var/tmp/rpm-tmp.24704: cannot open

  Even something as simple as

	%post
	exit 0

  generates that.  I do know that truss says that the script in question
  was created (with the exit 0 inside), but it's unlinked after rpm forks
  but before /bin/sh is execve()'ed.  Could be an issue with file
  descriptors across exec() calls or maybe something else.  It's also on
  my list of minor issues to look into.


Tim
--
Tim Mooney                              mooney dogbert cc ndsu NoDak edu
Information Technology Services         (701) 231-1076 (Voice)
Room 242-J6, IACC Building              (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164