On 14/02/15 05:08, James wrote: > Alan McKinnon <alan.mckinnon <at> gmail.com> writes: > > ... >> Any special reason why you don't instead download the sources and build >> them yourself with PREFIX=/usr/local ? > > Lots of errant codes flying everywhere so you have to pull a code audit > to see what's in the raw tarballs before building. That takes way too much > time. I'm working on setting up several more workstations for coding to > isolate them from my main system. This approach you suggest is: error prone, > takes too much time, and I'm lazy and sometimes even stupid. > I need a structure methodology to be a one man extreme_hack_prolific > system that prevents me from doing stupid things, whilst I'm distracted. >
> > rpm is just a wrapper around a an archive with instructions on how to build and or install it. I have more experience with rpm's but I believe debs are the same. Just unwrap your .rpm/.deb file of choice and install it manually (the binaries/code are usually in a zip inside the rpm). You should in most cases also be able to get a source rpm (which I suspect you are talking about anyway, but binaries do work deps permitting. you can install rpm and then install your package via rpm - seem to remember doing this with .debs somehow too. deps are a problem but usually workable. and why set up a workstation? - this sort of thing is tailor made for vm's. Create a base for your experiments with essential packages, settings etc, snapshot it (golden master) and then throwaway->restore when finished with that iteration. There are package managers besides gentoo/protage that can do a source build/install and track the files on gentoo - though portage will not know about it (rpm is one :) and lastly, what do mean error prone? - to me a manual install is the ONLY way you can build a proper ebuild that catches most of the problems. In the (admittedly few) ebuilds I have done an occasional human error is nothing compared to system problems for a difficult package. BillK
