On 7/25/2011 12:05 PM, R P Herrold wrote:
else has already done it. That is, building an RPM is always more work than doing a source install and often imposes inconvenient restraints like only permitting a single version to be running at once, and doesn't give you any guarantee that you won't have to repeat that extra work when the distribution changes. If you aren't planning to repeat that install on other machines, where's the payback for the extra work and constraints?
The rant at the start of this thread was about a migration into C6, so of course, your predicate condition: 'you aren't planning to repeat that install' does not apply
My condition in that case was that you couldn't count on the RPM to work anyway once the distribution changes. So you'll likely be repeating that extra effort anyway. And of course your next install may be on a non-RPM based system, making any rpm-packaging effort moot.
The disciplne and benefit of identifying and solving dependencies in a packaged system, rather than splatting as root over system libraries upon which other packages depend [also, the same isue using CPAN shell to 'solve' a problem, rather than packaging, as ZM has many such [1]] is obvious, and needs no further advocacy, even for a single install; the 'straw man' about setting different private library paths assumes that the person building such even comprehends that there is an issue in play. Not likely
Now you are talking about very different things. Installing your own stuff in /usr/local (as most source installs would do unless you go out of your way to subvert it) bypasses the issue of overwriting disto-supplied files. You are right, of course, that outdated and missing libraries in the base disto are a complex problem particularly for languages/apps that have their own update/install concepts, no matter how you try to solve it. But a simple 'build an rpm' isn't going to fix those complications.