Karen Tung wrote: > Hi Dave, > > Thanks for the code review. My responses are below. > > Dave Miner wrote: >> General question that occurred to me: how big is the contents file >> that's generated? Just want to understand impacts on CD size. > The size of the file is 4.2K. >> slimcd_gen_cd_content: >> >> It appears to me that most of the exclusions listed in the comments at >> 47 and the code at 98 are debris from some of the early iterations in >> the live CD during prototyping; in particular, find's for >> >> *.cpio >> *.bz2 >> *.7zip >> > Yes, finds for *.cpio, *.bz2 and *.7zip are all empty. I kept those > there because I was trying to > move the logic of the existing transfer module code. I just remove it. > It is less confusing that way. > >> all come up empty on a build 108 global image. Also, shouldn't the >> .image_info file be excluded here? > I will add it to the list here. I will also remove the ICT code that > delete the file.
Not to play fetch-a-rock here, but .catalog could also be handled this way. >> Out of curiosity, any particular reason you didn't use Python here, >> since it was basically a move of existing code? The reason I mention >> is that there's no shared definition of the contents file path between >> the code here and the transfer module, which would at least be easier >> to accomplish if you'd used Python for this half. > No particular reason. It's easier for me to do it in ksh since I know > that better than Python, and it takes less lines > of code to accomplish the same thing. If you think it is better to do > it Python, I can change it. I'm not going to be militant on it, I guess, but I would have looked at it as an opportunity to get a little better at Python. Lack of shared definitions means this is a little more fragile than it needs to be, though I don't anticipate a lot of change in this particular piece. No further comments, no need for re-review if you also move .catalog's handling. Dave
