Re: Is there a UNIX standard for where to install local tools?

On 2009-06-30, Stachu 'Dozzie' K. <dozzie@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
The problem is that doesn't work well. It just works, but from
perfection its far, far away. First, you loose dependency tracking.

When I first started using Linux, package managers with dependency
tracking had just become the new rage. I decided to try out Red Hat and
everything worked great until the dependency database became corrupt. I
have since avoided package management systems with dependency tracking.

I had a similar issue on a system where I was forced to start with a Debian
install (I usually start from a heavily customized version of Slackware).
Trying to remove PAM from the system and reduce it down to the bare
bones that I could restart from, I ended up having to force the package
management to do things that it didn't want to do. The package management
system quickly corrupted forcing me to manually find and remove files.

I think package managers are great for installations; but, after that
I refrain from using then and install everything from source.

Second, you loose information what and in what version is installed in
the system. Third, you loose easy way to upgrade. Fourth, without

First, I keep the source for anything that I install in /usr/local/src
therefore it is clear what version I have installed. Second, most
utilities will allow you to get the version with something like --version.

the system. Third, you loose easy way to upgrade. Fourth, without

Upgrades are handled in the same manner.

building scripts you loose easy way to build newer version with the same
flags or add flags if you find two months after instalation that some of

Not if you save your build commands to a shell build script.

them are missing. And think about applying some patches to compiled
software and recompiling it in the future or installing the same
software on dozen systems.

No problem. Drop the patch in the source directory, add it to your build
script, and rebuild.

software and recompiling it in the future or installing the same
software on dozen systems.

A tarball is just as easy to roll out to thousands of systems as a rpm or
deb package is.

You loose all of this and gain just mess in your system.

Never had a problem since I have learned to reject dependecy tracking
systems.

I have, on several occasions, uninstalled the distro's package and
compiled the version I want. It presents no problems at all.
Except when dependency resolving of your package manager sees you have
no OpenSSL library and installs the one from distribution while you have
installed OpenSSL in /usr/local.

By avoiding package management competely I avoid that problem.

Which distro doen't have OpenSSL available?
Wrong question. The correct is if your distro does have it compiled in
the version you require and with options you need (e.g. with ECC
support). Try installing it with `./configure && make mess' method and
then installing anything else from package repository.

The bottom line is that you can use either paradigm effectively; but, don't
mix them. Some distributions are entirely source based. They work well.
Slackware uses a package management system without dependency tracking. It
works well. Package managers with dependency tracking also works well as
long as the dependency database doesn't get corrupted. Pick one method and
stick to it.
.

Relevant Pages

  • Re: Studio Dumps Windows For Linux.
    ... That will definitely screw up a Windows registry over time. ... Isn't an install of a Linux app essentially a copy and paste ... Unix systems started getting package managers. ... When package management first came out, I was strongly against it, since ...
    (rec.audio.pro)
  • Re: [Full-Disclosure] Fw: Red Hat Linux end-of-life update and tr ansition planning
    ... I have to disagree with rpms thought -- I like slack's package management tool. ... > my own packages, rpm is easy as. ... > is so much easier to write custom install scripts. ... Virgin Blue \ Pacific Blue respects your ...
    (Full-Disclosure)
  • Re: What are good alternatives
    ... package management system are Slack and LFS. ... I mean firsthand by trying to install GNUcash from its tarball without ... > complicate getting under the hood to fix problems. ...
    (comp.os.linux.misc)
  • Re: Package Managers
    ... In my opinion, a package management ... way to install, remove, and update ... things that a package management system ...
    (comp.os.linux.misc)
  • Re: Package/Build-From-Source Management
    ... Install the checkinstall package. ... the package management system is aware of the software. ...
    (Ubuntu)