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

Re: [PATCH] DriverDiscs again - fixes according to review

> > I guess I'm confused here.  Your next point down you want libraries
> > for rpm.
> > But you are opposed to it for cpio? 
> I want the libarchive to go there, just not now, since we need to test
> this first and the cipo code was tested and works. So before replacing
> any components, I would like to concentrate on the overall design
> testing than on particular pieces which could be replaced later.

This just seems like creating more work for yourself in the future,
though.  Because you didn't go with libarchive to begin with, you had to
come up with something else.  Now the proposal is to remove what will
have been written, tested, and reviewed when something else has been
written, tested, and reviewed.

I think we're capable of discussing both the overall design and the
current implementation at the same time, and I would really prefer to
see the current implementation make use of a library for this particular
section.  Remember that the less code you've written, the fewer places
you'll be responsible for bugs in the future.

I still stand by my comment that once something's in, finding the time
to go back and rework it is going to be extremely difficult.  Something
else is going to come up that'll require your attention, and then we'll
be stuck supporting our own cpio for the next zillion years.  You can
see places where this happened to other people throughout RHEL4 and
RHEL5 anaconda.

> > Since this was largely new code entering
> > the
> > installer, it felt like as good a time as any.  I don't think any of
> > the
> > cleanups pointed out were very difficult.
> Right now there is just not enough time to rewrite string handling.
> But this is just the introduction patchset, so it would be possible
> during testing, when we can actually see if our cleanup breaks stuff
> or not.. at the moment, we have no way how to test it properly.

Why isn't there enough time to get the string handling stuff done right
now?  Given the tools like checked_asprintf and what glib provides, it
seems like it should be a pretty straightforward fix.

I'd really like to see these sorts of things done right to begin with so
we don't have to do additional work on them in the future, assuming we
can ever make the time to get around to it.

> > I'd like to see comments from other people on the team regarding the
> > driver
> > disk patch set.
> Me too... and also on the question of possibly including updates.img
> on the driver disc.

Ugh, do we have to?  And if so, how automatic is it supposed to be?  You
can already specify an updates image location via updates= or via a
kickstart command.  We also automatically look for one in various
locations relative to the stage2 image location.  If we are
automatically looking in a driver disk, it seems like we're really
overloading the driver disk concept in a way that doesn't really make
sense.  After all, what do updates to whatever tree you're installing
and a driver disk have in common?

- Chris

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