From: Michel <da...@re...> - 2000-09-19 09:46:30
|
One thing I noticed in the 'main' packages is that the tarball contains another gzipped tarball with the modules. This doesn't make sense as it prevents gzip from exploiting full compression for the 'outer' one. I suggest either putting the modules in a modules/<version>/ subdirectory or at least not gzipping their tarball. Another point is that I have forgotten to include the modules in the latest 2.4 test package. It would be nice if from time to time, someone who builds a working 2.4 kernel puts it in a package and uploads it. Michel -- Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast Debian GNU/Linux (powerpc,i386) user \ member of XFree86 and the DRI project |
From: Alan B. <al...@ms...> - 2000-09-19 10:22:02
|
hi, > One thing I noticed in the 'main' packages is that the tarball contains > another gzipped tarball with the modules. This doesn't make sense as it > prevents gzip from exploiting full compression for the 'outer' one. I suggest > either putting the modules in a modules/<version>/ subdirectory or at least > not gzipping their tarball. this doesnt make sense...if gzip follows all sane rules of compression, then it doesnt matter whether you compress it all, or just compress what isnt already compressed. ie take 4 directories, either tar them and gzip them, or tar and gzip each of them and tar and gzip the resulting .tgz's, the result should be the same in file size. the reason why I chose the 'encapsulate' method for the modules is it makes it 4x easier for users to install the modules, as they dont have to make directories etc, untarring the modules package from root will do the work for them (i cant imagine how many user problems we'd face if they had to go around actually making directories! ;-) - after all, just see the number of problem emails that just HAVING modules creates :-)) > Another point is that I have forgotten to include the modules in the latest > 2.4 test package. It would be nice if from time to time, someone who builds a > working 2.4 kernel puts it in a package and uploads it. i cant build a kernel from the 2.3 CVS tree (the first time I've ever tried was last night) I was going to make a '2.4' version similar to the vmapus-kit of 000814. it fails in the /arch/kernel direcrtory, problems with fork.c alan |
From: Michel <da...@re...> - 2000-09-19 11:27:06
|
Alan Buxey wrote: > > One thing I noticed in the 'main' packages is that the tarball contains > > another gzipped tarball with the modules. This doesn't make sense as it > > prevents gzip from exploiting full compression for the 'outer' one. I > > suggest either putting the modules in a modules/<version>/ subdirectory or > > at least not gzipping their tarball. > > this doesnt make sense...if gzip follows all sane rules of compression, > then it doesnt matter whether you compress it all, or just compress what > isnt already compressed. > > ie take 4 directories, either tar them and gzip them, or tar and gzip each > of them and tar and gzip the resulting .tgz's, the result should be the > same in file size. It isn't, try it. The point is that gzip can't further compress the gzipped contents of the tarball, but it may compress the original contents better because there is more data to eliminate redundancy in. > the reason why I chose the 'encapsulate' method for the modules is it > makes it 4x easier for users to install the modules, as they dont have to > make directories etc, untarring the modules package from root will do the > work for them (i cant imagine how many user problems we'd face if they had > to go around actually making directories! ;-) - after all, just see the > number of problem emails that just HAVING modules creates :-)) I disagree. What's so hard about 'cp -R modules/* /lib/modules/' ? I consider that easier than having to figure out how to use tar. You could put in a script which does that and maybe runs depmod -a or whatever. > > Another point is that I have forgotten to include the modules in the > > latest 2.4 test package. It would be nice if from time to time, someone > > who builds a working 2.4 kernel puts it in a package and uploads it. > > i cant build a kernel from the 2.3 CVS tree (the first time I've ever > tried was last night) I was going to make a '2.4' version similar to the > vmapus-kit of 000814. > > it fails in the /arch/kernel direcrtory, problems with fork.c What about posting the problems? Michel -- Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast Debian GNU/Linux (powerpc,i386) user \ member of XFree86 and the DRI project |
From: Alan B. <al...@ms...> - 2000-09-19 11:40:49
|
hi, > It isn't, try it. > > The point is that gzip can't further compress the gzipped contents of the > tarball, but it may compress the original contents better because there is > more data to eliminate redundancy in. okay, matching what is available in the other files, i get it > I disagree. What's so hard about 'cp -R modules/* /lib/modules/' ? I consider > that easier than having to figure out how to use tar. You could put in a > script which does that and maybe runs depmod -a or whatever. I'll work on this...would just keeping them in a plain .tar be a start anyway? > > it fails in the /arch/kernel direcrtory, problems with fork.c > > What about posting the problems? it happened late last0night, i havent had time to go further on this. I'll download the 2.4test kernel image from sourceforge and use the .config that that came with and see if the error is still present. if so, then I'll continue and post the errors. alan |
From: Michel <da...@re...> - 2000-09-19 12:42:51
|
Alan Buxey wrote: > > I disagree. What's so hard about 'cp -R modules/* /lib/modules/' ? I > > consider that easier than having to figure out how to use tar. You could > > put in a script which does that and maybe runs depmod -a or whatever. > > I'll work on this...would just keeping them in a plain .tar be a start > anyway? That would be better, still I don't see the need for a tarball. Wouldn't it even be easier for you to just cp -R the modules? Michel -- Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast Debian GNU/Linux (powerpc,i386) user \ member of XFree86 and the DRI project |