Subject: package management ('hard drive' is OT now)
From: Mac Mason (macmasta@ak.net)
Date: Wed Nov 19 2003 - 13:53:36 AKST
> Hi Mac,
>
> Just for fun, I went and copied the complete quote so you can draw your
> own conclusions - as I obviously don't have any experience with this.
> here it is:
> The problem came when I tried to go back, and use apt again. The entire
> apt system maintained its own list of installed packages with no
> awareness of what was actually on the system, so as soon as it fell out
> of sink, the entire apt manageer collapsed. My experience on Redhat and
> Mandrake were similar.
My conclusion is that this guy should take a loon at man
$PACKAGE_MANAGER...apt has a way of telling itself it has a package;
emerge has -i (inject) and rpm (at worst) has --nodeps.
And 'parsing the system looking for packages' collapses under its own
weight very, very fast; for example, if I need python, I could look for
binaries called 'python' and then see what 'python -V' gives to see if
it's the right one.
But: keeping track of the information about 'which software calls what
binary what, and what binaries need what flags to run' and so on,
immediately becomes a giant hassle; not as much work as a package
manager, but almost. And you really don't want a script wandering around
your system executing random binaries with arbitrary flags, do you? I
sure don't.
Not to mention that a system like portage, ports, or apt keeps track of
huge numbers of distribution-specific patches (RH and MDK rpms probably
do this as well); what if my installed-by-hand package wants my wwwroot
in /home/httpd, while my distro wants it in /var/www? Should we teach
our newfangled script-gadget to do all that for us too?
The problem gets way too large, way too fast. The solution is roughly as
plain as the nose on your face: if you want something that isn't in the
(say, portage) tree:
1) Submit a bug. "I want X!"
2) Get the source, and read a few docs to see what it depends on.
3) On gentoo, see if you can cut-and-paste the build process into the
ebuild template; if that works, submit it to your bug and use your
local ebuild to install the package.
4) If not, or if you don't have time to try to get that working, compile
it with ./configure --prefix=/usr/local or /opt/name_of_package and
update your $path to include it (only necessary in /opt case).
5) Make sure you've satisfied the dependencies for your package (step 2)
before you do step 4; fix as many of these as you can with your
packaging system.
6) wait for (distro of choice) to complete the package-manager-based
version of your program, and switch to it when done.
Shorter version: If they haven't got it, remember to add
--prefix=/usr/local to your ./configure command when you do it by hand.
~Mac~
PS: Not sure about the UNIX experience of readers, so I'll cover this
real quick: /usr ('unix system resources', not 'user') is where
everything that isn't absolutely imperative to boot the system. In
general, on linux, programs get installd in /usr/bin, /usr/lib, and so
on. Software that is 'local' to the system (like, say, your
outside-the-package-manager-spec-install) goes in /usr/local/bin,
/usr/local/lib, and so on. /opt is for programs that don't follow the
classic UNIX division into bin, lib, include, and so on, (like
OpenOffice) or (quite commonly on linux machines) software that's
closed-source (in my case, vmware, realplayer, and so on).
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
This archive was generated by hypermail 2a23 : Wed Nov 19 2003 - 13:53:30 AKST