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.
--
Les Mikesell
lesmikesell at gmail.com