On 14 Oct 2003, Bart Garst wrote:
> > There are times when I want to try out a new program (which we will
> > call program A, not original... But it will work) and I find out that
> > there isn't a package for program A on my disco.. So I get the source
> > and compile it. Well I find out that program A needs library B and my
> > version of library B is only 1.2.55.3.4.1 not 1.2.55.3.4.2 that it
> > requires. As luck would have it there isn't an update for library B on
That has hit me many times.
> > Over time, my original distro, be it Debian, mandrake, or whatever,
> > mutates into some other creature all together where package management
> > is holding on a thin thread that is drawn tight and ready to snap
> > because of all the non distro libraries, programs, etc I've installed.
> > How to you guys deal with this?
If you build and install from source, then don't overwrite your operating
system's provided own versions of same software. Use /usr/local/ for
example. Many Makefiles and configure scripts allow defining the
installation location (like --prefix=/usr/local).
Then force your new software that depends on it to use the /usr/local
version.
In most cases, it is okay to have two versions of the same software
installed at the same time.
> My preference is: If the software provider (of the program I want to
> try) didn't think far enough ahead to have their stuff run on as many
> systems as possible, then they probably didn't think very far ahead with
> regards to other design aspects.
That may be true. If software is written using standard POSIX and
historical Unix features, then it is easy (and often works automatically)
when built on other systems.
But in some cases, a software developer may not have the time, knowledge
or quickly-available resources to test and develop on many systems.
I often have people ask me to develop my software, like vm-pop3d and
mailout, for Tru64 Unix, AIX, Solaris, etc. I don't have the time to
continually test and/or learn about the differences between the many
developer environments -- even though I am interested.
> Further more, if they can't provide a package for something as common as
> Mandrake, RedHat, or Debian, further suspicions as to the quality of
> their stuff arise.
Also, software developers and maintainers often don't have the knowledge,
experience and/or resources to test and build specifications or
ready-to-use packages for many Linux distributions and Unix flavours.
For example, I am not interested in spending my free time to test and
build and then provide packages for mailout for the IRIX operating system.
I am not interested in using my valuable time to test and build and
provide packages for gethost Red Hat.
Of course, many developers/maintainers are happy when others volunteer to
provide packages (and related) for other operating systems.
Also, commercial vendors may not have the interest to spend money to
package all software (because it also means continueing maintenance for
that package).
> For those times when this doesn't work and I must compile the lib (or
> whatever), I do my best to give it its own home in /usr/local/libname.
> Plus I keep a log of the install (`make install &> log&; tail -f
> --pid=xxxx log`). Now if I decide I don't want it, I can thoroughly get
> rid of it.
I use pkgsrc (even under Linux) to manage third-party software builds,
dependencies, configurations, installations, etc.
Jeremy C. Reed
http://bsd.reedmedia.net/
(text/plain)