[prev] [thread] [next] [lurker] [Date index for 2005/08/08]
On Sat, Aug 06, 2005 at 08:40:04AM -0500, Peter da Silva wrote: > > But nooooooooo, I > > can't do that because it put files all over the fucking place and I > > have no way of ever being able to get it fully off of my system. > > When I get software that's not a Port or an OSX bundle, my (admittedly > imperfect) solution for this is "make --prefix=/usr/test/packagename" > unless I'm pretty sure I'm going to keep the beggar around. > > Failing that, you can always run "make install" onto a file and strip > all the turd locations out of that. > > But since I've got a Mac, my previous dislike for the UNIX scattershot > package installation has become closer to a hate. It's not as bad as the > Windows "hide outdated updates for system files in 3rd party programs > and then install them on top of the right ones, then add a program to > watch for changes and undo them so when you really DO want to install > stuff it defeats you", but solutions like "/opt/package" and symlink trees > that I originally puked at have become more attractive over the years. I'll often go so far as to ./configure --prefix=/tmp/meat/usr (yes, I usually use "meat" as a throwaway directory name), and after "make install" I'll cd into /tmp/meat, make whatever modifications are appropriate (such as adding an init.d script), "tar czf ../progname.tar.gz *", and convert it to package appropriate for the local system. Under Debian, this means using alien to build a .deb file; Slackware/BSD-style package tools can take a .tgz directly, if I recall correctly. Given that local packages are a great way to keep your system cruft level from getting out of control, the fact that Red Hat doesn't include a convenient mechanism from making an RPM from a directory tree or .tar.gz file is a separate hate. As are build systems in general -- you'd think that given the amount of software written in the computing world, making tools that could easily and successfully build and install software and do things like recognize which files should be rebuilt after touching a header would be a higher priority. Nooooo, let's use automake to build the configure script to generate the Makefiles that recursively invoke make to spackle over the problem -- that way when something breaks, it's REALLY hateful! Hmmmm... spackle... now there's a not-too-hateful product... too bad it isn't software. ChetThere's stuff above here
Generated at 21:00 on 01 Sep 2005 by mariachi 0.52