> yep we didn't use libarchive, because we had no clue anything like > that existed.. It is pretty new library and nobody mentined it when I > was doing my research, looking for cpio libs. So we have a code which > works and can be replaced with libarchive. It is also true, that we > will have to do more fixing later. But we will get some real world > exposure now, instead of waiting and fixing and tweaking the > unreleased code to the last moment. The problem here is that we'll be getting real world exposure on the cpio code that's not even going to be in the final release. If there are bugs in it, will you spend time fixing the bugs in something that's never going to be shipped? Yeah of course you will have fixing to do later. That's expected, and no one's suggesting that your code must be perfect before it can get committed. If that were the standard, nothing would ever go in. However, replacing a major portion of the code is not just fixing - it's reimplementing. It sucks that you didn't find out about libarchive until late, but at least now you know about it. > The code for driver discs uses glib ang checked_asprintf at least on > the pieces we had to modify. I was talking about all the code > surrounding it. Fox example the static buffers stuff. I'm not against > changing it, but you guys keep coming with cleanup ideas when we are > desperate to get at least some testing time. If your new code is using those things already, that's great and probably sufficient. It'll be easier to check when there's an updated patch set like Peter asked for. I guess it would be really nice to update the things in that same area since you're already working there, but maybe we can figure something out. We're not just looking for work to keep you busy. The fact is that we almost never look at driver disk stuff - it doesn't get tested, it doesn't get looked at by any of us for ways it can be improved. And now that you're working on it, you're making us look at these files to see all the deficiencies. It's just the perfect time to get other things updated too. > We never said the code is final and perfect. We only need at least > something in the main tree to start with. This is almost impossible to > debug outside of master anaconda. Moreover this feature is completely > outside the scope of common instalation, the code doesn't even get > called without proper Driver Disc. Yeah I know, working on the loader is pretty brutal and that's why I'd love to see it go away completely. However the fact that it so rarely gets used means bugs in it will go unnoticed for several minor releases until they suddenly crop up as emergencies and everyone's forgotten how the code works. > > 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? > > > > It should be fully automatic I'm affraid. So if we could check the > version and arch of the updates.img somehow, it wouldn't be that hard > to implement. It's not that it'd be hard to implement, it's that the scope of this automatic driver disk thing just keeps increasing to involve more and more stuff all the time. We have mechanisms for specifying updates images. What's wrong with using one of those? Further, version and arch checks are something that updates images do not have at all right now, meaning we'd either need to add it to all (which is a major change of behavior) or just for this one path (which introduces a pretty gross inconsistency). - Chris _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
