Not checking for installed RPMs would be fairly simple to implement.  

However, that's not the way it's done in real life -- there you have a
seed set of RPMs the form a minimal core to allow rpm(1) to do it's job.
We clearly have those things available to us as the image build process
does that now.  This is a better approach, as we're closer to actual
practice, rather than trying to invent some other mechanism.

I'll take a look at that.

I'll also take a look at ignoring the installed base, if that's truly as
simple a fix as I think it is, then I'll do that too, so we can at least
try it out -- better to pick from two alternatives than one.

Both approaches will fit well in the current code design.

-- 
David N. Lombard
 
My comments represent my opinions, not those of Intel Corporation.

> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:oscar-devel-
> [EMAIL PROTECTED] On Behalf Of Jason Brechin
> Sent: Friday, May 14, 2004 6:27 AM
> To: Jeff Squyres
> Cc: OSCAR development
> Subject: Re: [Oscar-devel] Client image
> 
> I thought I remembered seeing some option in update-rpms to ignore the
> filesystem and just check deps based on listed packages.
> 
> Dave?
> 
> Jason
> 
> 
> On Thu, 2004-05-13 at 23:28, Jeff Squyres wrote:
> > Ok, a bunch of problems has been fixed.  You can get all the way up
> > through installing the server non-core RPMs (with a bunch of oda
> > uninitialized variable warnings).  But now we have a new problem.
> >
> > When building the client image, we get two lists of RPMs: the
> > "oscarsample" RPM list for the distro and the list of RPMs from the
> > packages.  Previously, we just used all those RPMs to build the
image,
> and
> > that was that.
> >
> > Recally, however, that per the Tuesday phone call, I've removed
"libaio"
> > from LAM's RPM list.  So now the install-both-RPM-lists mechanism no
> > longer works -- because the LAM RPM dependencies fail because libaio
is
> > missing.
> >
> > But wait -- DepMan should have caught this, right?
> >
> > Yikes!  This is a place where DepMan integration was skipped.  So I
> added
> > it.  Buuutttt... not really.  Here's the problem:
> >
> > update-rpms checks against both the cache and the installed system
to
> come
> > up with a list of RPMs that need to be installed.  Hence, you get a
list
> > of RPMs suitable passing to "rpm -ivh ...".
> >
> > But that's no good because we're checking against the root
filesystem,
> and
> > therefore we don't get a "pure" list of RPMs to install into an
image
> > (i.e., there's lots of RPMs missing in the output because they're
> already
> > installed on the server).
> >
> > There's a chroot() function for DepMan so that you can check against
> > images.  But there's no image yet, so this is useless.  :-\
> >
> > Anyone got any ideas here?
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: SourceForge.net Broadband
> Sign-up now for SourceForge Broadband and get the fastest
> 6.0/768 connection for only $19.95/mo for the first 3 months!
> http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
> _______________________________________________
> Oscar-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/oscar-devel


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id%62&alloc_ida84&op=click
_______________________________________________
Oscar-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/oscar-devel

Reply via email to