[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [PATCH 6/7] Add the cpio routine and interface to librpm

Hash: SHA1

On Tue, 8 Dec 2009, Jon Masters wrote:

On Mon, 2009-12-07 at 10:44 -1000, David Cantrell wrote:

I really don't want to see cpio code or even rpmlib code in the loader.  As
previously mentioned, I think libarchive would work fine for cpio usage, but I
was thinking about this a bit more and wonder why we can't just force a run of
'/bin/rpm -Ivh --nodeps --force' from inside the loader.

The problem always was that there was no RPM, and in discussions with
Martin I took away that there was some pressure/history for not adding
new stuff like cpio and rpm into the loader environment. That was
obviously our first discussion - just shove in those utilities and be
done - but there has to be some upper size limit on what can go in and
I'm curious if folks are now quite willing to pull these things in.

That is true, and we had that discussion at FUDCon Toronto the other day.  We
have historically limited the size of initrd.img due to various requirements.
e.g., supporting floppy boot.

We have relaxed those requirements though we do still have a "soft" goal of
keeping the initrd small.

I really feel Martin's pain as I've recently been looking at RPM format
stuff for another project, and I did wind up having cpio and rpm around
after I did the bare minimum of poking inside the RPM directly.

If forcing a run of rpm was what you two were initially talking about, I
really think that's the right approach.  The way I see things now is that we
will have to grow _some_ support in the initrd to support driver disks in
this style.  That's either going to /bin/rpm and what it links with that we
don't already have -or- cpio/libarchive and rpmlib.  The space differences
there are most likely minimal.

In this case, I also think about the necessary interaction that loader needs
to have with what we are doing.  In this case, I think that forcing the run of
rpm is sufficient.  Compare this to the removal of urls.c and moving to
libcurl rather than just exec'ing the curl(1) program.  In that case, getting
callback capability to display a progress bar was useful.

The requirements are the loader are not really hard and final, but that's why
we have these discussions.

- -- David Cantrell <dcantrell redhat com>
Red Hat / Honolulu, HI

Version: GnuPG v1.4.10 (GNU/Linux)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]