> > 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 _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
