Hi, 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. > > > > 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. 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. 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. > > > > 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? > 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. And if we have to? Ask our partners.. I'm able to shoot automatic kickstart&shell scripts execution ideas down, but this is something they are pushing hard to get and it is not unreasonable. Martin _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
