Ralph Shumaker wrote: > Gus Wirth wrote: >> Ralph Shumaker wrote: >> >>> Gus Wirth wrote: >>>.. >> No, please read the book. Right now you have no clue. It will take a >> while for you to learn enough to do this. I highly recommend working >> through the samples in the book. The only reason I know this stuff is >> because I have read the book and have been rebuilding packages for >> several years. >> > > Is this one of the things a person needs to know to do linux system > admin work? I'm tempted to find the quickest path to a working gnumeric > 1.7.91 install. But I at least have a workaround for the print problems > in 1.6.3, despite how inconvenient it is. And it *does* appeal to me to > learn system admin stuff. And at the moment, this problem helps with > motivation to learn. > >> >>> My goal is to get gnumeric 1.7.91 installed and working. If I have to >>> learn more than I ever wanted to know about ./configure and ./make and >>> ./make install, then so be it. I may forget parts of it later, but it >>> will be easier the next time I need to do it. >>> >> >> You have a long road ahead. >> > > That's not quite so encouraging. :-\ > ;)
I think it's neat you are interested in this stuff. The 'comfort' I can offer is that you are jumping into some of the more complicated parts of the puzzle. If the standard ./configure, make # make install don't work, there _may_ be a good opportunity to learn something by trying to figure out what's wrong -- up to a point(!). But if you start to feel buried, it may be just one of those cases where you have too big a problem for your experience level (or that of <heh> many of the others of us here, too). On this particular case, it may be that it's just not very easy to compile the later release in the earlier environment -- a clue might be it it were, why isn't it already available? The reasons for it not being easy are worth asking about. It may be that you are looking at changes that were done as part of an all-or-nothing change to a major part of the system -- a bunch of inter-operating libraries and other system components may have changed all at once (sort of what often happens with each distribution major version jump). When that happens, it's relatively rare for anyone to spend much time back-porting pieces of that total package deal. If you still find it interesting, as Gus says, it helps to read some of the docs specifically about packaging. One thought I have is that the rpm stuff is worth looking at in 2 passes: one to get a feel for what packagers do, and what things they worry about. Then after some hard-time with the configure stuff (and friends), a re-reading of rpm will probably start to make real sense. The configure step is just one part of a approach to building lower-level "packages", called the "gnu autoconf approach" (or something close to that). Some of this is hard slogging. And this hard part is built on top of other non-trivial things, including (eventually) make which has books of its own. I would be glad to take some lectures on this general subject, 'cause what part of it I do know is only self-taught in bits and pieces. Then you are probably also aware that rpm and other common packaging systems all add their contributions on top of the "upstream sources" (the output of originating software authors) which is (usually) in this configure-arrangement. Why it's done that way is worth another question. Whether it works as well as it should -- well, you've already seen some of that discussion, eh? ;-) It probably sounds like I am trying to discourage you, but my point is it's a tall drink, and you can't get it all in one swallow. I believe it _is_ possible to pick up a lot of useful things even in small steps, so long as it really interests you and you keep at it. Regards, ..jim (anybody still awake?) -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
