Joined: Oct. 2006
||Posted: Jan. 08 2008,13:20
|Quote (WDef @ Dec. 18 2007,18:13)|
I could be missing something but I don't quite follow why you want to do this sort of thing to uci/unc files at all. They don't use ramdisk. In particular, running scripts to prune header files seems risky to me. You only have to inadvertently bork one character to break the header for some build.
Personally I think it's better to leave all files in these two extension types alone. I don't prune them at all, and like to be able to find the readmes etc in these extensions and often refer to them. It only means a bigger download. Leaving the files in place also can provide dependency headers and libs ready to use for compiling an upgrade, and might provide useful evidence about the source of problems with an extension.
And I'm not sure I trust stripped binaries unless the build does it for you anyway, but maybe that's not entirely rational ...? I suppose a stripped binary may have a smaller footprint once loaded into memory.
Pruning is a good idea for .dsl extensions, so you can apply all of these techniques to that extension type.
I can see there is a type of aesthetic pleasure in getting a package size down for its own sake though?
My apologies -- I totally missed your post and didn't read it until just now.
Firstly, thanks for the very well-thought-out reply.
I agree with everything you said, especially what you said concerning README files. I mean, most of the time, no one reads them, except in those situations where you really can't figure out how to use the software, which is when they can really save you a lot of time. Also, I just thought of an important factor: People who are on dial-up are not so keen to hunt for docs online.
So, I think I will try to put README files in extensions.
Also: Yes, I agree that there is an aesthetic pleasure solely in reducing the package size. But the real Big Idea is to have the whole distro working altogether, that is to say, all the little pieces working together.