On 9/17/2010 3:30 PM, m.roth at 5-cent.us wrote: > >> All I'm saying is that it often turns out to be a whole lot more work >> than the initial 'configure, make, make install', so you either have to >> train the users to do their own copies in their own space so it will >> scale, or be very careful about how much of this you take on. And I'm >> saying this from experience. It's not much different from writing your >> own code where the initial cut is about 10% of the work of maintaining >> it - and if the upstream project goes away or takes a direction not >> compatible with your use, that's where you end up anyway. > > Having spent far more of my career as a software person, let me say that > what I've installed not from rpms or other packages has been nowhere near > as much work as writing it... esp. when you factor in creature feep, er, > feature creep, and "oh, I meant this, not *that*...." I think it is pretty hard to draw a line between code and custom configuration and what you have to do to keep them working as other things change. For example I once ran smail with some custom tweaks to work with binary attachments from a proprietary (AT&T) PC mail program and uucp. And some glue between that, hylafax, and a custom print spooler. They were, ummm, non-trivial to keep working over a period of several years, especially when smail sort of disappeared. But that was back before there were packaged versions of much of anything and you couldn't even count on updates to compile. The code that I controlled directly wasn't quite the same kind of problem. If you have different users needing these things on the same machine you must at least have run into situations where someone needs one version of a CPAN module or a new php/python/mysql version when at the same time someone else is running something that won't work with it. You might have run into the CPAN issue if you installed something like RT in the Centos 4 era. -- Les Mikesell lesmikesell at gmail.com