in case it's useful, here's my crach-course of hard-knocks on HOW TO
GET A PACKAGE OPERATIONAL in debian these days (i.e. april 2000--of course,
with code being added all the time, debian changes by the minute and
this
may become obsolete next tuesday--or seven years from now...)
Oliver Elphick wrote:
>
> w trillich wrote:
> ># su postgres
> >> cd /usr/lib/postgresql/test/regress
> >> make runtest
[snip]
> >./regress.sh: ../../config.guess: No such file or directory
[snip]
> >=============== installing PL/pgSQL... =================
> >Cannot find the file /usr/lib/postgresql/lib/plpgsql.so
>
> You need postgresql-pl, and postgresql-contrib, I think.
>
> That's another dependency to go in. That shows how many people have run
> the test package!
see, oliver's problem is that he doesn't know when to throw his hands
in the air and take off running for the hills... he keeps on being
helpful, darn it.
0. OBJECTIVE
okay. in order to get "postgresql-test" to work, according to the
guidance of the debian wonkmeister, i'll try the to do the
old "apt-get install" on these two new packages:
postgresql-pl
postgresql-contrib
here goes...
======================
= here we go--the world-renowned
= TRILLICH PATTERN FOR SUCCESSFUL* DEBIN INSTALL:
======================
1. WHICH DISTRIBUTION?
you'll be using apt-get to install debian things. (as of
april 2000, i hear this is the favored method.)
decide if you want packages or whole batch upgrades from
slink (debian 2.1)
potato (debian 2.2)
woody (debian 2.3 -- very experimental as i understand it)
and set your configuration files accordingly.
learn what you need to configure and where, here:
# man apt-get
# man apt-cache
# man apt.conf (/etc/apt/sapt.conf)
# man sources.list (/etc/apt/sources.list)
and at
http://www.debian.org/
click "installation instructions" under "Distribution"
for even more.
there's WAY more there than you'll probably ever need,
but browse thru the manpages so you won't be in the dark.
basically you'll usually only use
# apt-get install packageOne package_two
after your configuration is set, and
# apt-get --reinstall install this_package thatPackage
if you need to steamroll something
the old way to install things was
# dselect (screen-friendly point & select interface)
# dpkg (worked behind the scenes with dselect)
now i still used dpkg to hammer something down, but for the
most part stick with apt-get.
until something goes haywire. (just wait.)
2. BACKUP?
if i had any useful data or settings to preserve, i'd do so now.
email it to myself, shuffle it off to floppy, gzip it up in my
home directory, off to a jaz--no, wait, i might want it back...
files are available in *.rpm format. there is a utility
debian offers (alien) to translate those gadgets into debian
*.deb packages.
regarding those rpm files: DO NOT GO THERE unless you are
desparate (or using redhat or one of its close cousins). it
may work, but it's no longer the preferred way of going about
this sort of thing for debian folk like you and me. not any
more. use "APT-GET" (or when the interface is ready, "APT"
itself).
3. APT-GET INSTALL
# apt-get install postgresql-{pl,contrib}
those are the two packages i wanted.
initial try fails with install errors--missing files, unresolved
dependencies, verious snags hither and yon. i'd almost be
disappointed if it didn't, by now. roll with the punches.
so i step back a bit, and 'set phasers to obliterate' since my
initial try fails.
4. DPKG --REMOVE
# dpkg -r postgresql-{pl,test,contrib}
note i'm removing the two i just had install troubles with,
AND the original dastardly creep that's causing the headaches
to begin with.
4a. DPKG --PURGE
# dpkg --purge postgresql-{pl,test,contrib}
in theory, --purge does everything that --remove does, plus a bit
more (namely removing config files). but it's more satisfactory
to do it in two passes--feels like you get to shoot it, and then
bury it. very fulfilling. (reward yourself now and then, you
deserve it.)
and let me warn you: even purge won't purge everything.
"can't remove xyzzy: directory not empty" is a message you'll
see often. it's just a hollow directory with an old file here
and there, so you can blast it by hand (rm -i -r xyzzy, be
careful to check the path you type before pressing return)
or just let it go since it'll be re-created momentarily.
once i get here i'm all clear. everything is gone. i'm tabula
rasa (blank slate), ready to try again. now--retry:
5. APT-GET (again. if you can get away with just one, congratulations)
# apt-get install postgresql-{pl,test,contrib}
think of this as going back to step three, adding the
named of other packages you just purged.
if all doesn't go well, i try again, sometimes deinstalling an
uber-package... i.e. one that is crucial for the ones i'm depending
on. reinstalling it can clear up lots of things. in this instance,
that would be postgresql itself. if you were having trouble with
libdbi-perl, say, uninstalling all of perl would certainly
wake up SOMETHING. that's my theory, anyhow...
then, like the redneck sex guide says, 'repeat as necessary'.
if i get a serious error message, like
Checking for GNU cc in disguise and/or its version number...
gccvers.c:1: stdio.h: No such file or directory
*** WHOA THERE!!! ***
Your C compiler "cc" doesn't seem to be working!
You'd better start hunting for one and let me know about it.
then i'm stuck and have to figure out what's wrong before
i can go on.
other times package A depends on package B which isn't installed
or configured yet. if that's all the warning messages imply,
just hammer through another "apt-get install *" or two.
since the messages can fly fast and furious, use control-S (^S)
to stop and control-Q (^Q) to restart your display if you need
to, and shift-pageUP and shift-pageDOWN to scroll around, if
you're at the console... take notes or cut & paste the important
stuff so you can make an informed decision as to your next step.
once everything installs without any aborts (even tho there may
be a warning or 'file not found--skipping', you might be able to
go ahead):
6. ENVIRONMENT
presuming it's all installed, you gotta prepare your environment
to accomodate your goal. in my case, postgresql needs some variables
set so it knows where to look for various items; plus, i've got to
change to a different user id (the master pgsql user is postgres).
whatever you're doing may require a specific user id or certain
environmental variables. examples include
cd path chdir to where you need to be
chown userid.groupid files set user/group ownership of files
chmod -+rwx files to set permissions on files
setenv v=gunk environment variables (in csh)
v=gunk; export v environment variables (in sh)
su userid log in to another user id
there may be others to watch for, so stay alert...
in my case, here's what i needed:
# cd /usr/lib/postgresql/test/regress
# su postgres
> echo $PATH
/usr/lib/postgresql/bin/:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
> make all test
cd input; make all; cd ..
make[1]: Entering directory `/usr/lib/postgresql/test/regress/input'
Makefile:15: ../../../Makefile.global: No such file or directory
make[1]: *** No rule to make target `../../../Makefile.global'. Stop.
make[1]: Leaving directory `/usr/lib/postgresql/test/regress/input'
cd output; make all; cd ..
make[1]: Entering directory `/usr/lib/postgresql/test/regress/output'
Makefile:15: ../../../Makefile.global: No such file or directory
make[1]: *** No rule to make target `../../../Makefile.global'. Stop.
make[1]: Leaving directory `/usr/lib/postgresql/test/regress/output'
make -C ../../../contrib/spi REFINT_VERBOSE=1 refint.so \
autoinc.so
make: *** ../../../contrib/spi: No such file or directory. Stop.
make: *** [all] Error 2
so i still have troubles.
it mentions some files it's looking for, that it can't find. based
on the current directory,
../../../Makefile.global
would be found in
/usr/lib/Makefile.global
which seems unlikely. (makefiles are always hanging around with a
sprinkling of source files hither and yon--it's unlikely that you'd
find one at the top level of a primary system directory. [i think.])
so something seems screwy.
unfortunately Makefile is ubiquitous, and likely to be rather
pervasive throughout a debian installation, so searching for it
probably won't yield much in the way of results. (or rather, too
much/many results, like looking for a needle in a haystack.)
it's also looking for another item:
../../../contrib/spi
which would be
/usr/lib/contrib/spi
there's nothing glaring about this one; "spi" is an unusual name
and likely to be a directory (no dot in "spi"). maybe we can
find all the "spi" items and learn something from the search....
7. SEEK: DPKG -L, DPKG -S
use dpkg -L to list all files for a certain module, or dpkg -S for
modules that contain files matching a certain pattern. if you
get a huge list of items, use grep and more/pager/less to filter
the results... if you can't figure it out yourself with
this info, it'll help the genius on the list find it... the
genius who's got all the answers under his/her scalp.
so based on the "contrib" part of the path it's looking for
(../../../contrib/spi) so i'd guess it was looking for something
embedded within the "postgresql-contrib" package i'd just tried
to install.
so i look for "spi" files in the "postgresql-contrib" module
like this:
# dpkg -L postgresql-contrib | grep spi | more
/usr/lib/postgresql/modules/README.spi
/usr/share/doc/postgresql-contrib/spi
/usr/share/doc/postgresql-contrib/spi/README.MAX
/usr/share/doc/postgresql-contrib/spi/preprocessor
/usr/share/doc/postgresql-contrib/spi/preprocessor/README.MAX
/usr/share/doc/postgresql-contrib/spi/README.gz
so according to the module design (dpkg -L) there are TWO
"spi" items in the *-contrib package: one is a readme file
in /usr/lib, the other is a directory /usr/share/doc with
sub-items in. none of those "spi" items come close to matching
the apparent intended location of ../../.. which maps to /usr/lib.
what's the cause? i don't know. but i seem to have the package
designer's ear, so i'll ask by posting this mostrous message
to the list...
not giving up just yet--
the "make all runtest" dies on the "all" part and didn't
even get to the "runtest" part. maybe "runtest" depends on
"all"... here's how to find out:
> setenv PGLIB /usr/lib/postgresql/lib
> make runtest
all went well! except for the failed tests which
mostly appear to be in the eleventy-seventh digit of floating
point numbers... although there are some unnerving diffs:
*** expected/abstime.out Sun Jan 4 21:35:19 1998
--- results/abstime.out Thu Apr 13 19:31:39 2000
***************
*** 96,103 ****
|Sun Jan 14 03:14:21 1973 PST
|Mon May 01 00:30:30 1995 PDT
|epoch
! |current
! (4 rows)
QUERY: SELECT '' AS three, ABSTIME_TBL.*
WHERE (ABSTIME_TBL.f1 + '@ 3 year'::reltime)
--- 96,102 ----
|Sun Jan 14 03:14:21 1973 PST
|Mon May 01 00:30:30 1995 PDT
|epoch
! (3 rows)
QUERY: SELECT '' AS three, ABSTIME_TBL.*
WHERE (ABSTIME_TBL.f1 + '@ 3 year'::reltime)
[note: i snipped a few display cols off the 'horology' diff:]
*** expected/horology.out Wed Apr 14 21:19:02 1999
--- results/horology.out Thu Apr 13 19:31:40 2000
***************
*** 55,61 ****
|@ 5 mons |Sun Jul 28 18:32:01 1996 PDT
|@ 5 mons 12 hours |Mon Jul 29 06:32:01 1996 PDT
|@ 5 mons |Mon Jul 29 18:32:01 1996 PDT
! |@ 5 mons 12 hours |Thu Aug 01 06:32:01 1996 PDT
|@ 5 mons |Thu Aug 01 18:32:01 1996 PDT
|@ 5 mons 12 hours |Fri Aug 02 06:32:01 1996 PDT
|@ 14 secs ago |Mon Dec 30 17:31:47 1996 PST
--- 55,61
|@ 5 mons |Sun Jul 28 18:32:01 1996 PDT
|@ 5 mons 12 hours |Mon Jul 29 06:32:01 1996 PDT
|@ 5 mons |Mon Jul 29 18:32:01 1996 PDT
! |@ 5 mons 12 hours |Tue Jul 30 06:32:01 1996 PDT
|@ 5 mons |Thu Aug 01 18:32:01 1996 PDT
|@ 5 mons 12 hours |Fri Aug 02 06:32:01 1996 PDT
|@ 14 secs ago |Mon Dec 30 17:31:47 1996 PST
*** expected/triggers.out Wed Feb 18 07:15:07 1998
--- results/triggers.out Thu Apr 13 19:32:12 2000
***************
*** 50,66 ****
QUERY: insert into fkeys values (60, '6', 4);
ERROR: check_fkeys_pkey2_exist: tuple references non-existing key
in fkeys2
QUERY: delete from pkeys where pkey1 = 30 and pkey2 = '3';
- NOTICE: check_pkeys_fkey_cascade: 1 tuple(s) of fkeys are deleted
ERROR: check_fkeys2_fkey_restrict: tuple referenced in fkeys
QUERY: delete from pkeys where pkey1 = 40 and pkey2 = '4';
- NOTICE: check_pkeys_fkey_cascade: 1 tuple(s) of fkeys are deleted
- NOTICE: check_pkeys_fkey_cascade: 1 tuple(s) of fkeys2 are deleted
QUERY: update pkeys set pkey1 = 7, pkey2 = '70' where pkey1 = 50
and pkey2 = '5';
- NOTICE: check_pkeys_fkey_cascade: 1 tuple(s) of fkeys are deleted
ERROR: check_fkeys2_fkey_restrict: tuple referenced in fkeys
QUERY: update pkeys set pkey1 = 7, pkey2 = '70' where pkey1 = 10
and pkey2 = '1';
- NOTICE: check_pkeys_fkey_cascade: 1 tuple(s) of fkeys are deleted
- NOTICE: check_pkeys_fkey_cascade: 1 tuple(s) of fkeys2 are deleted
QUERY: DROP TABLE pkeys;
QUERY: DROP TABLE fkeys;
QUERY: DROP TABLE fkeys2;
--- 50,60 ----
that's how i do it. your mileage may vary.
p.s.
here's another oddity... is the server down?
# apt-get install pgaccess
Reading Package Lists... Done
Building Dependency Tree... Done
The following extra packages will be installed:
libpgtcl
The following NEW packages will be installed:
libpgtcl pgaccess
0 packages upgraded, 2 newly installed, 0 to remove and 1 not upgraded.
Need to get 193kB of archives. After unpacking 1126kB will be used.
Do you want to continue? [Y/n] y
Err http://http.us.debian.org frozen/main libpgtcl 6.5.3-17
404 Not Found
Err http://http.us.debian.org frozen/main pgaccess 6.5.3-17
404 Not Found
Failed to fetch
http://http.us.debian.org/debian/dists/frozen/main/binary-i386/libs/libpgtcl_6.5.3-17.deb
404 Not Found
Failed to fetch
http://http.us.debian.org/debian/dists/frozen/main/binary-i386/misc/pgaccess_6.5.3-17.deb
404 Not Found
E: Unable to fetch some archives, maybe try with --fix-missing?
but i don't know if i need this one...
*successful in the sense that my computer hasn't caught fire.
