On May 23, 2006, at 3:57 PM, Steve Juranich wrote:
Tim Mooney wrote:
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)? ;-)
Okay, first there are the "build dependencies", tools that are
necessary to
actually compile, these should be available on the system, but we
need to
provide them if they are not:
1) tar, gzip & patch to extract the tarball and apply any necessary
patches.
2) C compiler (preferably GCC).
3) GNU Make (which depends on ...?)
Dunno if rpm needs GNU make, perhaps these days. OTOH, rpm's needs
are pretty small,
so I'll be happy to fiddle out whatever GNU make dependencies there are.
Next are the RPM prerequisites, things that RPM itself needs to
build. We
will most likely need to provide these:
1) The BeeCrypt library.
Untar beecrypt into the top level directory, rpm will use the
internal version, adding the sumbols to librpmio.
(Note: that's also true with neon/sqlite. However, building external
is way way easier usually).
2) The Neon library (what does this depend on?)
Add sqlite3 (if desired) and elfutils (if on a elf system) here.
(Aside: Berkeley DB can be dumped with a little bit of effort, using
sqlite3 instead. Still, rpm has
been used far far more with Berkeley DB than sqlite3, so there may
still be a few surprises.)
3) Python
Python can be dumped for bootstrapping.
"Optional dependencies" that can be skipped if the right flags are
given to
the configure script (technically, Python would go here, but we're
looking
at using SMART to do some of the work, so Python gets bumped up,
plus it's
really cool):
1) Perl
Perl can be dumped for bootstrapping.
2) Lua (really?)
Really. lua is internal however. You may need readline, but current
lua internal to rpm does not need.
3) gettext (we won't be needing NLS).
Add --disable-nls.
4) SELinux (we don't need this either).
Add --disable-selinux
5) Java
6) Tcl
These are not needed at all afaik.
Then the actual act of compiling RPM would go here. It would get
installed
into some /local/area. I'd then run /local/area/bin/rpm --initdb.
In almost all cases --initdb is unneeded. The remaining n eed is to do
mkdir -p ..../var/lib/rpm
if rpm is invoked with --root. Otherwise won't hurt or help.
To finalize the bootstrap, I'd need to create some virtual package
defining
what the system provides (things like /bin/sh, libc, libstdc++, and
the
like).
Yep.
Question:
Would I want to reinstall Python, BeeCrypt, Neon, and RPM from RPMs
using
the new bootstrap rpm, or would I be better off just creating more
virtual
packages that "provide" the right things for the system to get into
a good
state?
Depends on what you want. rpm can be built with internal or external
versions,
and you may want to manage the software with rpm (or not). Only you
can say.
So am I close, or have I missed something horribly important? Any
pointers
in the right direction would be greatly appreciated. I am, of course,
assuming that I'll get to a point in my own checked out version of
the code
when I can do a `make dist' and create a suitable tarball for use in
distribution.
Thanks for the pointers about building on Solaris, I'm sure they'll
come in
handy.
Aside from the niggling problem that Tim Mooney has reported with
elfutils, rpm
on solaris should be pretty easy. Used to build out-of-the-box until
my ipx drive croaked ;-)
Good luck!
73 de Jeff
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
