Hi, > >... > >If, on the other hand, you treat the source code as the 'definative' > >documentation, then by keeping it around I know that there is nothing > >about my system that I cannot find out, and I never have to resort > >to trial and error to work out how something works. > > "Works" in what way? For most user purposes, man command_name or > command_name --help is sufficient to work out how something "works". If > you mean how it is designed to work, then yes, you certainly need the > source, but even so, that's only if you don't "agree" with the way it's > designed, or you want to modify the design. For a normal user, there's > very little need to resort to reading the source just to use the > application (boy, if that was true, Linux *really* wouldn't be ready for > the desktop!).
Ok, here is a quick example of something I would have dived into the source for yesterday had it not been for the fact that I couln't find any related '.c' files in my source directory..... When I emerged and ran 'grip', I found that clicking on the help menus did nothing. I thought I might have been missing some files, so I tried for a man page: 2.gentoo:/root> man grip No manual entry for grip Running 'grip --help' gives me a list of command line options, but nothing to shed light on the non-working menu... In the end I booted SuSE and read the help menu documentation there to answer my immediate query (I want to know the % escapes for tweaking the generated file and directory names...).. Without the source, you are back in the Windows situation where problems are sorted out by trial and error, folklore and reinstalling... While I am at it, anyone know what the problem with the grip help menu is on gentoo? > >Plus, of course, there is the added bonus that if the feature you > >are looking for isn't there, you can add it in. Or if the way > >something works isn't obvious from the source, it is easy to temporarily > >add the odd diagnostic. > > Fair enough, but that doesn't mean that every installed source has to be > extracted on your system because 1) most sources do actually work, both > in terms of compiling properly, and the compiled application working > properly, thus they do not need to be diagnosed, and 2) if you're > missing a feature and want to code it, you should be using the > application's CVS/Subversion source anyway, which will put the extracted > and current source on your system, so you can help improve the project > as a whole. There's not a lot of point in adjusting the release source > code, when some fixes may already exist in CVS towards the next release. To me that is a bit like saying you only need to install the man pages of the applications you are actually using. I feel that if you are going to install the application, you should install what you need to maintain it. If I knew in advance what was going to need fixing, (or trawling though to to find out how to make something to work..), then I would fix/solve it as part of the install process. Having the sources all unpacked also has the benefit of allowing me to grep through them - for instance if I want to look for examples of how a particular library has been used, or who creates a certain temp file... You are of course right about the CVS stuff for serious mods, but there are times when a quick hack is needed to test something, and only if it turns out to be a mod that would be generally useful would one bother with the CVS tree. > >It is also useful when writing new code to be able to look at existing > >source to make sure you are not re-inventing things and are following > >best practice. It is amazing how often you find that a library already > >exists to handle something you were about to code from scratch... > > Again, this doesn't seem to indicate that you'd need *every single > source* extracted on your system, but only the ones that bear some > relationship to something you might actually code. But it's your system. It is more a case of having what I 'might' need - same argument as having all the man pages, even though I have only used a subset to date. It would slow me down to much if I had to extract each man page from a tar ball before I could look at it. > >In theory I could unpack a tarball, but that is a lot more > >effort than reading a file with is already available and in a > >predictable place. > > Seems to me that you could write a script to unpack just the tarballs > you want unpacked to a known location, but that's just me; I've never > considered unpacking tarballs to be a lot of effort-- certainly not when > you could do it as a cron job. The point being, you're clearly not an > "average user", so you have special needs for your source tarballs. > Gentoo is certainly flexible enough to accomodate them (for example, the > KEEP_TEMP business suggested earlier), but because you have special > needs/desires, you have to make a small effort to make sure they are met > to your requirements. I'll look into that. The tricky bit was always working out the emerge stuff so that the source would be always up to date and reflect what is actually running. I guess you don't miss the source unless you have gotten used to having it always easily at hand. > >For me, being able to do that is one of the main benefits of an > >open source system. Being free is not the major issue. > > Nor for me; what I like is being able to customize my system for my > personal needs, and being able to contribute to the OS as a whole. > > But free (in either sense) is nothing to sneeze at, either. :) Agreed. Regards, DigbyT -- Digby R. S. Tarvin [EMAIL PROTECTED] http://www.digbyt.com -- [email protected] mailing list
