From: UnixOS2 Archive
To: "UnixOS2 Archive" <UnixOS2_Archive at unixos2.com>
Date: Sun, 15 Dec 2002 04:43:48 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600
Subject: [UnixOS2_Archive] No. 399

**************************************************
Saturday 14 December 2002
 Number  399
**************************************************

Subjects for today
 
1  Re:  Ncurses UnixOS/2 package : Stefan Neis <neis at cdc.informatik.tu-darmstadt.de>
2  Re:  Building Autoconf from original source : Stefan Neis <neis at cdc.informatik.tu-darmstadt.de>
3  Re:  Building Autoconf from original source : Stefan Neis <neis at cdc.informatik.tu-darmstadt.de>
4  Re:  libunixos2 (was: sysexits.h) : Stefan Neis <neis at cdc.informatik.tu-darmstadt.de>
5  Re:  libunixos2 (was: sysexits.h) : Andrew MacIntyre <andymac at bullseye.apana.org.au>
6  Re:  Building Autoconf from original source : Yuri Dario" <warp at os2power.com>
7  Re:  Building Autoconf from original source : John Poltorak <jp at eyup.org>
8  Re:  Building Autoconf from original source : John Poltorak <jp at eyup.org>
9  Re:  libunixos2 (was: sysexits.h) : John Poltorak <jp at eyup.org>
10  Re:  ANN: Pine 4.51 : John Poltorak <jp at eyup.org>
11  Re:  Zope Newbies : Jeff Robinson <jeffnik at anecho.mb.ca>
12   Make v3.79.2 problem : John Poltorak <jp at eyup.org>
13   [Re: srcdir] : John Poltorak <jp at eyup.org>
14  Re:  libunixos2 (was: sysexits.h) : Stefan Neis <neis at cdc.informatik.tu-darmstadt.de>
15  Re:  Building Autoconf from original source : Stefan Neis <neis at cdc.informatik.tu-darmstadt.de>
16  Re:  [Re: srcdir] : John Poltorak <jp at eyup.org>
17  Re:  Building Autoconf from original source : John Poltorak <jp at eyup.org>
18  Re:  Building Autoconf from original source : Yuri Dario" <warp at os2power.com>
19   REGEX.DLL : John Poltorak <jp at eyup.org>
20  Re:  Zope Newbies : Ted Sikora <tsikora at ntplx.net>
21   test -x (file on path) : John Poltorak <jp at eyup.org>
22   Zope Newbies : John Poltorak <jp at eyup.org>
23  Re:  Make v3.79.2 problem : Andreas Buening <andreas.buening at nexgo.de>
24  Re:  Building Autoconf from original source : Andreas Buening <andreas.buening at nexgo.de>
25  Re:  libunixos2 (was: sysexits.h) : Andreas Buening <andreas.buening at nexgo.de>
26   ANN: Pine 4.51 : Nicholas Sheppard <nps at zeta.org.au>
27  Re:  libunixos2 (was: sysexits.h) : Stefan Neis <neis at cdc.informatik.tu-darmstadt.de>
28  Re:  REGEX.DLL : Stefan Neis <neis at cdc.informatik.tu-darmstadt.de>
29  Re:  Building Autoconf from original source : Yuri Dario" <warp at os2power.com>
30  Re:  installpkg : Andreas Buening <andreas.buening at nexgo.de>

**= Email   1 ==========================**

Date:  Sun, 15 Dec 2002 00:11:10 +0100 (CET)
From:  Stefan Neis <neis at cdc.informatik.tu-darmstadt.de>
Subject:  Re:  Ncurses UnixOS/2 package

On Thu, 12 Dec 2002, Andreas Buening wrote:

> > > I think according to the FHS /usr/share/man is the correct location for
> > > man pages.
> > 
> > Personally, this location is fine with me, but it would be useful if
> > everyone accepted it.
> 
> I guess, you won't get any feedback on this issue. We already
> had a discussion about this.

Exactly. I seem to remember that there was a decision to follow FHS, so
what room is left for opinions? Just set a standard and criticize/complain 
when someone does not follow it ...

	Regards,
		Stefan


**= Email   2 ==========================**

Date:  Sun, 15 Dec 2002 00:17:57 +0100 (CET)
From:  Stefan Neis <neis at cdc.informatik.tu-darmstadt.de>
Subject:  Re:  Building Autoconf from original source

On Fri, 13 Dec 2002, John Poltorak wrote:

> I nearly always need to rebuild configure to have a chance of building the 
> app correctly on OS/2. It doesn't take long to run autoconf in any case.

That's certainly true for all scripts generated by old autoconf versions
(e.g. 2.13), i.e. currently for the vast majority, but shouldn't be the
case for those generated by current autoconf versions... (at least in
theory...). The problem is that not every software package will include
it's configure.in...

	Regards,
		Stefan


**= Email   3 ==========================**

Date:  Sun, 15 Dec 2002 00:29:11 +0100 (CET)
From:  Stefan Neis <neis at cdc.informatik.tu-darmstadt.de>
Subject:  Re:  Building Autoconf from original source

On Sat, 14 Dec 2002, John Poltorak wrote:

> The problem seems to occur when a drive letter is include in srcdir...
> 
> If anyone has tried installing Autoconf recently, could you try editing 
> the Makefile created by run configure, and just before running Make, 
> change srcdir in the Makefile so that has a full path including drive 
> letter, and see if you get the 'multiple target patterns' error when 
> running make.  

Sounds like the makefile is ending up with a line like
some_target: d:some_source_file
and is completely confused by the two ':' in a single line. 
Not sure what can be done about that, but building on a drive different
from the one the sources are placed on doesn't really sound like a
good idea - probably your only chance is to avoid the need for that. 

Personally, I'm positively sure I never tried using a drive letter in
specifying a source directory, so I can't comment on whether or not that
did ever work with any version of make, but I would be really surprised
if it did.

          Regards,
                 Stefan


**= Email   4 ==========================**

Date:  Sun, 15 Dec 2002 00:33:27 +0100 (CET)
From:  Stefan Neis <neis at cdc.informatik.tu-darmstadt.de>
Subject:  Re:  libunixos2 (was: sysexits.h)

On Sat, 14 Dec 2002, Andreas Buening wrote:

> For the next release I plan to add two static dummy libs. Both contain
> functions that are not supported by emx and can't be implemented like
> symlink() or chown().

Is it really impossible to implement chown() for HPFS386 partitions or
network drives? And what's the result? chown() always fails?

> If you have written any implementation of functions like chown(),
> fchown(), link(), symlink(), <insert your favorite here> for any
> unix-like package please submit them so that I can build them into
> the next libunixos2 release. Thanks!

What's the point in restarting POSIX/2 from scratch?

	Regards,
		Stefan
-- 
Micro$oft is not an answer. It is a question. The answer is 'no'.


**= Email   5 ==========================**

Date:  Sun, 15 Dec 2002 09:24:23 +1000 (est)
From:  Andrew MacIntyre <andymac at bullseye.apana.org.au>
Subject:  Re:  libunixos2 (was: sysexits.h)

On Sat, 14 Dec 2002, Andreas Buening wrote:

> For the next release I plan to add two static dummy libs. Both contain
> functions that are not supported by emx and can't be implemented like
> symlink() or chown(). The functions contained in the first library
> (os2dummy.a) will ever return an error ENOTSUP (function not supported)
> while the second library (os2links.a? - name suggestions are still
> accepted :-) ) will try to emulate this behaviour, e.g. chown() returns
> success, symlink() copies the file.

Having been through the link(2)/symlink(2) issues in helping Ted try and
get Mailman working, I have to say I question the utility of a simple file
copy implementation of either routine (even though I implemented link()
that way in a Python module for Mailman).  While it seems like a viable
approach, and would work well enough for some (even quite a few)
situations, the following limitations can bite hard:
 - stat() returns info about the copy, which may not be up to date;
 - link counts (in the case of link()ed files) aren't accurate;
 - where you want to symlink() to a directory, the disk space cost could
   be significant;
 - nested symlinks get _very_ messy to support.

I think I remember Holger Veit (sp?) mentioning that he was looking at
supporting link(2) & symlink(2) via EAs in his libemu project, but have no
idea whether that was just a plan or whether he had working code.

The EA approach is the only one that could get close enough to the
required semantics to deal with the vast majority of Unix code.  It is a
non-trivial exercise though as the required semantic support touches every
routine in libc that deals with the file system.

To make this worth while, dropin replacements for EMXLIBCS.DLL and
EMXLIBCM.DLL which contained the extra code necessary to do this (and
added the link() & symlink() routines etc) would make all extant EMX 0.9d
(and maybe 0.9c) packages instantly support - or at least understand -
this functionality.

I don't know what Eberhard Mattes' reaction would be to doing this if this
code were to be contributed.  Because the EMX stuff is GPL, the
replacements could be distributed anyway, but the confusion would be much
less if it could be handled as part of the EMX package.

BTW, I haven't signed up for this (yet) but I've given it some thought.

--
Andrew I MacIntyre                     "These thoughts are mine alone..."
E-mail: andymac at bullseye.apana.org.au  | Snail: PO Box 370
        andymac at pcug.org.au            |        Belconnen  ACT  2616
Web:    http://www.andymac.org/        |        Australia


**= Email   6 ==========================**

Date:  Sun, 15 Dec 2002 09:41:29 +0100 (CET)
From:  "Yuri Dario" <warp at os2power.com>
Subject:  Re:  Building Autoconf from original source

Hi John,

>variables srcdir and topsrcdir had paths set. The one which did work had 
>those two variables set to '.'. When I changed the srcdir on the former 
>Makefile, the error above disppeared.

I had the same error, and your solution fixed the problem also here.

I see that make is issuing a new warning:

make: $SHELL changed (was `/bin/sh', now `e:/bin/SH.EXE')

That's because of my 'SET SHELL=xxx' in config.sys (here from a long time): is 'set shell' really 
needed, or I can remove it?


Bye,

	Yuri Dario

/*
 * member of TeamOS/2 - Italy
 * http://www.quasarbbs.net/yuri
 * http://www.teamos2.it
 * http://www.opera.com/os2/
 */

**= Email   7 ==========================**

Date:  Sun, 15 Dec 2002 09:56:13 +0000
From:  John Poltorak <jp at eyup.org>
Subject:  Re:  Building Autoconf from original source

On Sun, Dec 15, 2002 at 12:29:11AM +0100, Stefan Neis wrote:
> On Sat, 14 Dec 2002, John Poltorak wrote:
> 
> > The problem seems to occur when a drive letter is include in srcdir...
> > 
> > If anyone has tried installing Autoconf recently, could you try editing 
> > the Makefile created by run configure, and just before running Make, 
> > change srcdir in the Makefile so that has a full path including drive 
> > letter, and see if you get the 'multiple target patterns' error when 
> > running make.  
> 
> Sounds like the makefile is ending up with a line like
> some_target: d:some_source_file
> and is completely confused by the two ':' in a single line. 
> Not sure what can be done about that, but building on a drive different
> from the one the sources are placed on doesn't really sound like a
> good idea - probably your only chance is to avoid the need for that. 

I have no idea why srcdir contains a full path. It isn't required since 
'.' is perfectly adequate in this case. This change has only started 
happening recently and I can't imagine what I have done to cause it.

How does configure decide what value to assign to this variable?

Maybe I can set it explicitly in the environment to '.' ...


>           Regards,
>                  Stefan


-- 
John


**= Email   8 ==========================**

Date:  Sun, 15 Dec 2002 10:09:31 +0000
From:  John Poltorak <jp at eyup.org>
Subject:  Re:  Building Autoconf from original source

On Sun, Dec 15, 2002 at 09:41:29AM +0100, Yuri Dario wrote:
> Hi John,
> 
> >variables srcdir and topsrcdir had paths set. The one which did work had 
> >those two variables set to '.'. When I changed the srcdir on the former 
> >Makefile, the error above disppeared.
> 
> I had the same error, and your solution fixed the problem also here.

Have you only started getting srcdir set as a full path recently?

Not so long since it was set to '.', but I can't remember when this change 
took place and don't recall making any significant changes to alter the 
value.
 
> I see that make is issuing a new warning:
> 
> make: $SHELL changed (was `/bin/sh', now `e:/bin/SH.EXE')

I always get this with Make v3.79.1. I don't perceive it as a problem.
 
> That's because of my 'SET SHELL=xxx' in config.sys (here from a long time): is 'set shell' really 
> needed, or I can remove it?


It's a problem setting a value in CONFIG.SYS years ago and now wondering 
why...

If you take it out you have no idea what might break.

Personally, I like to avoid setting variables in CONFIG.SYS and only do 
so when I think they are absolutely necessary.

 
> 
> Bye,
> 
> 	Yuri Dario
> 
> /*
>  * member of TeamOS/2 - Italy
>  * http://www.quasarbbs.net/yuri
>  * http://www.teamos2.it
>  * http://www.opera.com/os2/
>  */


-- 
John


**= Email   9 ==========================**

Date:  Sun, 15 Dec 2002 10:40:50 +0000
From:  John Poltorak <jp at eyup.org>
Subject:  Re:  libunixos2 (was: sysexits.h)

On Sun, Dec 15, 2002 at 12:33:27AM +0100, Stefan Neis wrote:
> On Sat, 14 Dec 2002, Andreas Buening wrote:
> 
> > For the next release I plan to add two static dummy libs. Both contain
> > functions that are not supported by emx and can't be implemented like
> > symlink() or chown().
> 
> Is it really impossible to implement chown() for HPFS386 partitions or
> network drives? And what's the result? chown() always fails?
> 
> > If you have written any implementation of functions like chown(),
> > fchown(), link(), symlink(), <insert your favorite here> for any
> > unix-like package please submit them so that I can build them into
> > the next libunixos2 release. Thanks!
> 
> What's the point in restarting POSIX/2 from scratch?

What is the current status of POSIX/2? It appears to be fairly stagnant.

Are there elements of it that we can currently integrate into UnixOS/2?

POSIX/2 was always a very ambitious, long term project, and I'm sure there 
are parts of it which could be used now. There is likely to be a large 
degree of overlap between POSIX/2 and libunixos2 and it would be a pity if 
all the hard work that went into wasn't generally usable. I understand 
Holger is planning to use some of it in developing LIBEMU, but we could 
probably make use of most of the headers now.

 
> 	Regards,
> 		Stefan
> -- 
> Micro$oft is not an answer. It is a question. The answer is 'no'.
> 


-- 
John



**= Email   10 ==========================**

Date:  Sun, 15 Dec 2002 11:19:32 +0000
From:  John Poltorak <jp at eyup.org>
Subject:  Re:  ANN: Pine 4.51

On Sun, Dec 15, 2002 at 09:12:38PM +1100, Nicholas Sheppard wrote:
> Hi all.
> 
> I've just uploaded Pine 4.51 for OS/2 to Hobbes and it should shortly
> appear in the usual place. This a is bug-fix release from the University
> of Washington. As always, more details are available from
> 
>     http://www.zeta.org.au/~nps/software/pine/en/index.html
> 
> As for Pine 4.50, I've compiled two versions of Pine 4.51. The standard
> version, available from Hobbes, has had no OS/2-specific changes. The
> new version, available from my web site, has had a couple of changes.
> 
> Most significantly, the mail servers can now be launched from an
> OS/2-style inetd. I haven't had time to test them thoroughly but they
> seem to work fine for basic mail reading. In particular, I haven't
> carefully examined the security of my log-in implementation so you
> may want to think carefully about how your machine might exposed if you
> use the new servers. Please report any bugs or security flaws to me so
> that I can fix them for the next release.

This sounds really good. At last I've got the chance of using an IMAP 
server. I don't know exactly how it works, but I'll certainly give it a 
try.

I also see two pop servers ipop2d and ipop3d. Presumably ipop3d is the 
one recommended...

BTW what is tmail? I didn't seen any mention of it in the docs. Should I 
look on the official Pine web site for further info?

 
> 	Nicholas S.
> 
> |\ Location: Wollongong, Australia  | Begin each day by telling yourself:
> |\ E-mail: nps at zeta.org.au          | today I shall be meeting with
> |  WWW: http://www.zeta.org.au/~nps | interference, ingratitude, insolence,
> |  ---> Cynicism & Negativity       | disloyalty, ill-will and selfishness...
> 
>                                       - Marcus Aurelius Antoninus


-- 
John



**= Email   11 ==========================**

Date:  Sun, 15 Dec 2002 12:13:49 -0600
From:  Jeff Robinson <jeffnik at anecho.mb.ca>
Subject:  Re:  Zope Newbies

John Poltorak wrote:
> For anyone (like myself) who has still to appreciate what wonderful things 
> we can do now that we have Zope available, have a look at:-
> 
> 
> http://www.zopenewbies.net/faq.html
> 
> 
> I'm hoping it clears things up for me, although I'll still end up buying a 
> book.
> 
> Any recommendations?
> 

I haven't had any experience with the print-books per se, though The 
Zope Book instantly comes to mind.  ( 
http://www.zope.org/Documentation/Books/ZopeBook/current/index_html )

This book is online via the Open Publication License, so it's a 
community development deal.  When they feel that the time is proper then 
they put it into print.  The Zope folks have made some big changes over 
the last while so I'm not certain how the current version of the book 
that is in print holds up to the online version.

This is the book that I used when I started learning how to use Zope, 
and it seemed to serve me quite well.

Jeff

-- 
----------------
Whatza JamochaMUD?
http://jamochamud.anecho.mb.ca

Or other stuff: http://www.anecho.mb.ca/~jeffnik
  -----------------------------------------------------------

  

**= Email   12 ==========================**

Date:  Sun, 15 Dec 2002 12:25:24 +0000
From:  John Poltorak <jp at eyup.org>
Subject:   Make v3.79.2 problem

There seems to be a problem with Make v3.79.2(a1) which prevents Autoconf 
being built.

I've found that specifying '--srcdir=.' with configure gets past the 
previous error, although I still don't understand how the error arises in 
the first place. However, I found that Make v3.79.1 works fine now, but if 
I use the later version, there is an error here:-


make[3]: Entering directory `U:/unixos2/workdir/autoconf-2.53/lib'
rm -f autom4te.cfg autom4te.tmp
sed -e 's, at SHELL\ at ,u:/bin/sh,g' -e 's, at PERL\ at ,u:/usr/bin/perl.exe,g' -e 
's, at bindir\ at ,u:/usr/local/bin,g' -e 
's, at datadir\ at ,u:/usr/local/share/autoconf,g' -e 
's, at prefix\ at ,u:/usr/local,g' -e 's, at autoconf-name\ at ,'`echo autoconf | sed 
's,x,x,'`',g' -e 's, at autoheader-name\ at ,'`echo autoheader | sed 
's,x,x,'`',g' -e 's, at autom4te-name\ at ,'`echo autom4te | sed 's,x,x,'`',g' 
-e 's, at M4\ at ,u:/usr/bin/m4.exe,g' -e 's, at AWK\ at ,awk,g' -e 
's, at VERSION\ at ,2.53,g' -e 's, at PACKAGE_NAME\ at ,GNU Autoconf,g' ./autom4te.in 
>autom4te.tmp
mv autom4te.tmp autom4te.cfg
make[3]: Leaving directory `U:/unixos2/workdir/autoconf-2.53/lib'
../../tests/autom4te				\
	--language=m4sugar			\
	--freeze			\
	--include=./..		\
	--include=..			\
	--output=m4sugar.m4f
AUTOM4TE.: cannot open u:/usr/local/share/autoconf/autom4te.cfg: No such file or directory
 at \UNIXOS2\WORKDIR\AUTOCONF-2.53\BIN\AUTOM4TE. line 428
make[2]: *** [m4sugar.m4f] Error 1
make[2]: Leaving directory `U:/unixos2/workdir/autoconf-2.53/lib/m4sugar'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `U:/unixos2/workdir/autoconf-2.53/lib'
make: *** [all-recursive] Error 1



-- 
John



**= Email   13 ==========================**

Date:  Sun, 15 Dec 2002 14:24:58 +0000
From:  John Poltorak <jp at eyup.org>
Subject:   [Re: srcdir]


--9vMzThJgcQTmkNcV
Content-Type: text/plain; charset=us-ascii

Here's a reply to my srcdir problem from the autoconf list.


-- 
John


--9vMzThJgcQTmkNcV
Content-Type: message/rfc822

Received: from monty-python.gnu.org by mail.eyup.org (IBM OS/2 SENDMAIL VERSION 2.03/2.0) id NAA332.11; Sun, 15 Dec 2002 13:46:27 GMT
Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org)
	by monty-python.gnu.org with esmtp (Exim 4.10.13)
	id 18NZ64-0003UZ-06
	for jp at eyup.org; Sun, 15 Dec 2002 08:46:20 -0500
Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13)
	id 18NZ5i-0003GQ-00
	for autoconf at gnu.org; Sun, 15 Dec 2002 08:45:58 -0500
Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13)
	id 18NZ5a-00032l-00
	for autoconf at gnu.org; Sun, 15 Dec 2002 08:45:51 -0500
Received: from parcival.faw.uni-ulm.de ([134.60.100.20]
	helo=gawain.faw.uni-ulm.de)
	by monty-python.gnu.org with smtp (Exim 4.10.13)	id 18NZ5Y-0002I9-00
	for autoconf at gnu.org; Sun, 15 Dec 2002 08:45:49 -0500
Received: (qmail 29691 invoked from network); 15 Dec 2002 13:45:56 -0000
Received: from ultra2.faw.uni-ulm.de (HELO mailserv.faw.uni-ulm.de)
	(172.16.15.2)
	by mailserv1.faw.uni-ulm.de with SMTP; 15 Dec 2002 13:45:54 -0000
Received: (qmail 1834 invoked by uid 0); 15 Dec 2002 13:45:18 -0000
Received: from dialin38.faw.uni-ulm.de (172.18.1.38)
  by mailserv.faw.uni-ulm.de with SMTP; 15 Dec 2002 13:45:18 -0000
From: Ralf Corsepius <corsepiu at faw.uni-ulm.de>
To: Autoconf List <autoconf at gnu.org>
In-Reply-To: <20021215114207.N88 at eyup.org>
References: <20021215114207.N88 at eyup.org>
Content-Type: text/plain
Organization: FAW Ulm
Message-Id: <1039960193.13391.21950.camel at mccallum.corsepiu.faw.uni-ulm.de>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.0 
Date: 15 Dec 2002 14:52:36 +0100
Content-Transfer-Encoding: 7bit
X-Spam: Pruefung durchlaufen
Subject: Re: srcdir
X-BeenThere: autoconf at gnu.org
X-Mailman-Version: 2.1b5
Precedence: list
List-Id: Discussion list for the autoconf build system <autoconf.gnu.org>
List-Help: <mailto:autoconf-request at gnu.org?subject=help>
List-Post: <mailto:autoconf at gnu.org>
List-Subscribe: <http://mail.gnu.org/mailman/listinfo/autoconf>,
	<mailto:autoconf-request at gnu.org?subject=subscribe>
List-Archive: <http://mail.gnu.org/pipermail/autoconf>
List-Unsubscribe: <http://mail.gnu.org/mailman/listinfo/autoconf>,
	<mailto:autoconf-request at gnu.org?subject=unsubscribe>
Sender: autoconf-bounces+jp=eyup.org at gnu.org
Errors-To: autoconf-bounces+jp=eyup.org at gnu.org

Am Son, 2002-12-15 um 12.42 schrieb John Poltorak:
> Can someone tell me in what circumstances srcdir gets resolved into a full 
> pathname?

Normally, srcdir is derived from 2 sources:
1. The value passed to --srcdir=<path>
2. The path used to point to the configure script, when running it, ie.
<path>/configure == <srcdir>/configure

[With 1. overriding 2. (ie. --srcdir=<path> overrides <path>/configure]

If you use an absolute path for one of these, srcdir will be absolute.

Ralf





--9vMzThJgcQTmkNcV--


**= Email   14 ==========================**

Date:  Sun, 15 Dec 2002 14:28:59 +0100 (CET)
From:  Stefan Neis <neis at cdc.informatik.tu-darmstadt.de>
Subject:  Re:  libunixos2 (was: sysexits.h)

On Sun, 15 Dec 2002, John Poltorak wrote:

> What is the current status of POSIX/2? It appears to be fairly stagnant.

For my needs, I'd call it "finished" and stable (unless you insist 
on having a DLL). What's to be done next is libemu, as far as I can see.

	Regards,
		Stefan
-- 
Micro$oft is not an answer. It is a question. The answer is 'no'.


**= Email   15 ==========================**

Date:  Sun, 15 Dec 2002 14:35:08 +0100 (CET)
From:  Stefan Neis <neis at cdc.informatik.tu-darmstadt.de>
Subject:  Re:  Building Autoconf from original source

On Sun, 15 Dec 2002, John Poltorak wrote:

> I have no idea why srcdir contains a full path. It isn't required since 
> '.' is perfectly adequate in this case. This change has only started 
> happening recently and I can't imagine what I have done to cause it.

Ah, I start to see the problem ...
Maybe a change in autoconf for better support of the more and more
common situation of build_dir != source_dir. I wonder what "they" are
using to determine the full path and how we could trick that routine
into omitting the drive letter (I suppose, we're on it's own, as that
problem again won't exist with cygwin and its
/cygdrive/drive_letter/path/file.ext approach.

	Regards,
		Stefan
-- 
Micro$oft is not an answer. It is a question. The answer is 'no'.


**= Email   16 ==========================**

Date:  Sun, 15 Dec 2002 14:36:30 +0000
From:  John Poltorak <jp at eyup.org>
Subject:  Re:  [Re: srcdir]

On Sun, Dec 15, 2002 at 02:24:58PM +0000, John Poltorak wrote:
> Here's a reply to my srcdir problem from the autoconf list.

> Am Son, 2002-12-15 um 12.42 schrieb John Poltorak:
> > Can someone tell me in what circumstances srcdir gets resolved into a full 
> > pathname?
> 
> Normally, srcdir is derived from 2 sources:
> 1. The value passed to --srcdir=<path>
> 2. The path used to point to the configure script, when running it, ie.
> <path>/configure == <srcdir>/configure
> 
> [With 1. overriding 2. (ie. --srcdir=<path> overrides <path>/configure]
> 
> If you use an absolute path for one of these, srcdir will be absolute.
> 
> Ralf


I can confirm that all I needed to do to get my script working was to 
change:-

configure

to:-

./configure


-- 
John



**= Email   17 ==========================**

Date:  Sun, 15 Dec 2002 14:57:04 +0000
From:  John Poltorak <jp at eyup.org>
Subject:  Re:  Building Autoconf from original source

On Sun, Dec 15, 2002 at 03:35:02PM +0100, Yuri Dario wrote:
> Hi John,
> 
> >Have you only started getting srcdir set as a full path recently?
> 
> I don't know, since it is the first time this problem surfaced here. But looking at older makefiles, 
> they have srcdir=. and builddir=.
> I think this changed with recent autoconf releases, since I was using 2.53 before upgrading to 
> 2.57

If you have a script which runs configure and it contains:-

configure

can you change it to:-

./configure

and see if it sorts out the srdir problem?

BTW, have you tried to add in to v2.57 the OS/2 patches made for v2.53b-r2 
on Hobbes? 

I'd like to include any OS/2 enhancements if they make my life easier, but 
I'm not entirely sure what would be missing out on by not applying them.



> Bye,
> 
> 	Yuri Dario
> 
> /*
>  * member of TeamOS/2 - Italy
>  * http://www.quasarbbs.net/yuri
>  * http://www.teamos2.it
>  * http://www.opera.com/os2/
>  */


-- 
John



**= Email   18 ==========================**

Date:  Sun, 15 Dec 2002 15:35:02 +0100 (CET)
From:  "Yuri Dario" <warp at os2power.com>
Subject:  Re:  Building Autoconf from original source

Hi John,

>Have you only started getting srcdir set as a full path recently?

I don't know, since it is the first time this problem surfaced here. But looking at older makefiles, 
they have srcdir=. and builddir=.
I think this changed with recent autoconf releases, since I was using 2.53 before upgrading to 
2.57

>If you take it out you have no idea what might break.
>Personally, I like to avoid setting variables in CONFIG.SYS and only do 
>so when I think they are absolutely necessary.

since I don't like extra config.sys statements, I will comment it and see what will happens.


Bye,

	Yuri Dario

/*
 * member of TeamOS/2 - Italy
 * http://www.quasarbbs.net/yuri
 * http://www.teamos2.it
 * http://www.opera.com/os2/
 */

**= Email   19 ==========================**

Date:  Sun, 15 Dec 2002 15:54:51 +0000
From:  John Poltorak <jp at eyup.org>
Subject:   REGEX.DLL



I'd like to build REGEX.DLL from source using either libunixos2 or 
posix/2.

Can anyone tell me how I can go about it?

There is a libregex on Hobbes but the regex.c which it contains is 
completely different to the one in libunixos and posix/2 does not contain 
a regex.c at all AFAICT.


-- 
John



**= Email   20 ==========================**

Date:  Sun, 15 Dec 2002 16:05:54 -0500
From:  Ted Sikora <tsikora at ntplx.net>
Subject:  Re:  Zope Newbies

Jeff Robinson wrote:
> 
> John Poltorak wrote:
> > For anyone (like myself) who has still to appreciate what wonderful things
> > we can do now that we have Zope available, have a look at:-
> >
> >
> > http://www.zopenewbies.net/faq.html
> >
> >
> > I'm hoping it clears things up for me, although I'll still end up buying a
> > book.
> >
> > Any recommendations?
> >
> 
> I haven't had any experience with the print-books per se, though The
> Zope Book instantly comes to mind.  (
> http://www.zope.org/Documentation/Books/ZopeBook/current/index_html )
> 
> This book is online via the Open Publication License, so it's a
> community development deal.  When they feel that the time is proper then
> they put it into print.  The Zope folks have made some big changes over
> the last while so I'm not certain how the current version of the book
> that is in print holds up to the online version.
> 
> This is the book that I used when I started learning how to use Zope,
> and it seemed to serve me quite well.
> 
> Jeff
> 

I think Amazon or that Geek(something) site has The Zope Book and The
Zope Cookbook in a bundled package real cheap. I added the FAQ to my
ZopeOS/2 page. We created a monster with rsync on OS/2. OS2Ports.com is
getting hammered all day. Rsync, FTP, and HTML. Looks like I may have to
shut down ftp public downloads if it continues... again!

--
Ted Sikora
tsikora at ntplx.net

**= Email   21 ==========================**

Date:  Sun, 15 Dec 2002 16:19:48 +0000
From:  John Poltorak <jp at eyup.org>
Subject:   test -x (file on path)


test -x can tell if a file is executable, but it seems to require a full 
path. How would I use it to check the %PATH% for a particular executable?

Or would I use something else?

I want to use the result to specify the subsequent action in a shell 
script. 

-- 
John




**= Email   22 ==========================**

Date:  Sun, 15 Dec 2002 17:49:46 +0000
From:  John Poltorak <jp at eyup.org>
Subject:   Zope Newbies


For anyone (like myself) who has still to appreciate what wonderful things 
we can do now that we have Zope available, have a look at:-


http://www.zopenewbies.net/faq.html


I'm hoping it clears things up for me, although I'll still end up buying a 
book.

Any recommendations?

-- 
John


**= Email   23 ==========================**

Date:  Sun, 15 Dec 2002 20:06:15 +0100
From:  Andreas Buening <andreas.buening at nexgo.de>
Subject:  Re:  Make v3.79.2 problem

John Poltorak wrote:
> 
> There seems to be a problem with Make v3.79.2(a1) which prevents Autoconf
> being built.

[snip]

If you still have the problem can you send me the complete
output of both make versions?
Btw., I've used 3.79.2a1 for several month without any problems.


Bye,
Andreas

-- 
One OS to rule them all, One OS to find them,
One OS to bring them all and in the darkness bind them
In the Land of Mordor where the Shadows lie.

**= Email   24 ==========================**

Date:  Sun, 15 Dec 2002 20:12:40 +0100
From:  Andreas Buening <andreas.buening at nexgo.de>
Subject:  Re:  Building Autoconf from original source

Yuri Dario wrote:
> 
> Hi John,
> 
> >variables srcdir and topsrcdir had paths set. The one which did work had
> >those two variables set to '.'. When I changed the srcdir on the former
> >Makefile, the error above disppeared.
> 
> I had the same error, and your solution fixed the problem also here.
> 
> I see that make is issuing a new warning:
> 
> make: $SHELL changed (was `/bin/sh', now `e:/bin/SH.EXE')
> 
> That's because of my 'SET SHELL=xxx' in config.sys (here from a long time): is 'set shell' really
> needed, or I can remove it?

make ignores $SHELL from your environment (at least it should to so).
That's a usual feature of the Unix versions of GNU make. Some people
set SHELL to their preferred interactive shell which might be
unsuitable for make.


Bye,
Andreas

-- 
One OS to rule them all, One OS to find them,
One OS to bring them all and in the darkness bind them
In the Land of Mordor where the Shadows lie.

**= Email   25 ==========================**

Date:  Sun, 15 Dec 2002 20:12:53 +0100
From:  Andreas Buening <andreas.buening at nexgo.de>
Subject:  Re:  libunixos2 (was: sysexits.h)

Andrew MacIntyre wrote:
> 
> On Sat, 14 Dec 2002, Andreas Buening wrote:
> 
> > For the next release I plan to add two static dummy libs. Both contain
> > functions that are not supported by emx and can't be implemented like
> > symlink() or chown(). The functions contained in the first library
> > (os2dummy.a) will ever return an error ENOTSUP (function not supported)
> > while the second library (os2links.a? - name suggestions are still
> > accepted :-) ) will try to emulate this behaviour, e.g. chown() returns
> > success, symlink() copies the file.
> 
> Having been through the link(2)/symlink(2) issues in helping Ted try and
> get Mailman working, I have to say I question the utility of a simple file
> copy implementation of either routine (even though I implemented link()
> that way in a Python module for Mailman).  While it seems like a viable
> approach, and would work well enough for some (even quite a few)
> situations, the following limitations can bite hard:
>  - stat() returns info about the copy, which may not be up to date;
>  - link counts (in the case of link()ed files) aren't accurate;
>  - where you want to symlink() to a directory, the disk space cost could
>    be significant;
>  - nested symlinks get _very_ messy to support.

[snip]

Yes, that's true. I realize that this can't be a general solution.
Consider the typical case: You download a package and try to
compiler but it fails because of "function symlink not found".
Instead of starting to hack the code you recompile with
"-los2dummy" so that "symlink" and other functions are available.
Then you try to run the program, may be it works (i.e. it
doesn't really need symlink() or can handle the case if symlink()
fails), may be not. Then you don't have to put a

#ifdef __EMX__
#define chown(x,y,z)
#endif

into 20 different source files.

However, I plan to release new versions of the file and
shell utilities. For them I need dummy versions of these
functions because the maintainer is not willing to put
dozens of ifdefs like that one above into the code.
Of course, ln or chown will fail with these replacement
functions. But e.g. ls will work even if ls requires readlink()
this function won't be called unless ls finds a link which
will never happen because there is no link on your file system.


Bye,
Andreas

-- 
One OS to rule them all, One OS to find them,
One OS to bring them all and in the darkness bind them
In the Land of Mordor where the Shadows lie.

**= Email   26 ==========================**

Date:  Sun, 15 Dec 2002 21:12:38 +1100 (AED)
From:  Nicholas Sheppard <nps at zeta.org.au>
Subject:   ANN: Pine 4.51

Hi all.

I've just uploaded Pine 4.51 for OS/2 to Hobbes and it should shortly
appear in the usual place. This a is bug-fix release from the University
of Washington. As always, more details are available from

    http://www.zeta.org.au/~nps/software/pine/en/index.html

As for Pine 4.50, I've compiled two versions of Pine 4.51. The standard
version, available from Hobbes, has had no OS/2-specific changes. The
new version, available from my web site, has had a couple of changes.

Most significantly, the mail servers can now be launched from an
OS/2-style inetd. I haven't had time to test them thoroughly but they
seem to work fine for basic mail reading. In particular, I haven't
carefully examined the security of my log-in implementation so you
may want to think carefully about how your machine might exposed if you
use the new servers. Please report any bugs or security flaws to me so
that I can fix them for the next release.

	Nicholas S.

|\ Location: Wollongong, Australia  | Begin each day by telling yourself:
|\ E-mail: nps at zeta.org.au          | today I shall be meeting with
|  WWW: http://www.zeta.org.au/~nps | interference, ingratitude, insolence,
|  ---> Cynicism & Negativity       | disloyalty, ill-will and selfishness...

                                      - Marcus Aurelius Antoninus

**= Email   27 ==========================**

Date:  Sun, 15 Dec 2002 22:02:13 +0100 (CET)
From:  Stefan Neis <neis at cdc.informatik.tu-darmstadt.de>
Subject:  Re:  libunixos2 (was: sysexits.h)

On Sun, 15 Dec 2002, Andreas Buening wrote:

> fails), may be not. Then you don't have to put a
> 
> #ifdef __EMX__
> #define chown(x,y,z)
> #endif
> 
> into 20 different source files.

Of course you should rather put it in _one_ suitable header file. ;-)
(At least, that's the theory, practice is sometimes slightly more ugly...)

	Regards,
		Stefan
-- 
Micro$oft is not an answer. It is a question. The answer is 'no'.


**= Email   28 ==========================**

Date:  Sun, 15 Dec 2002 22:12:57 +0100 (CET)
From:  Stefan Neis <neis at cdc.informatik.tu-darmstadt.de>
Subject:  Re:  REGEX.DLL

On Sun, 15 Dec 2002, John Poltorak wrote:

> posix/2 does not contain  a regex.c at all AFAICT.

Exactly. Its regex support is (as all the rest) taken from BSD and
the corresponding source code is in the directory libc\regex (6 .c files
and 4 .h files). And the whole is put into cExt.a which is a static
library.
If you want to build a REGEX.DLL, you'll decide which of the three
versions you mentioned you want to use and anything not compiled with/for
that particular version will at best silently ignore that REGEX.DLL (if
regex support is statically linked in via e.g. cExt.a) and at worst it
will (more or less silently) fail to work with that DLL installed.

Really, in the interest of not creating a hell of incompatible versions
I'd prefer very much to see such stuff linked statically until there's
an accepted replacement for EMX.DLL which includes those new functions.

	Regards,
		Stefan
-- 
Micro$oft is not an answer. It is a question. The answer is 'no'.


**= Email   29 ==========================**

Date:  Sun, 15 Dec 2002 22:58:13 +0100 (CET)
From:  "Yuri Dario" <warp at os2power.com>
Subject:  Re:  Building Autoconf from original source

Hi Andreas,

>> make: $SHELL changed (was `/bin/sh', now `e:/bin/SH.EXE')
>make ignores $SHELL from your environment (at least it should to so).
>That's a usual feature of the Unix versions of GNU make. Some people

here e:/bin/sh.exe is defined in the enviroment, so it seems that make (3.79.1) is ignoring the 
makefile.


Bye,

	Yuri Dario

/*
 * member of TeamOS/2 - Italy
 * http://www.quasarbbs.net/yuri
 * http://www.teamos2.it
 * http://www.opera.com/os2/
 */

**= Email   30 ==========================**

Date:  Sun, 15 Dec 2002 23:10:57 +0100
From:  Andreas Buening <andreas.buening at nexgo.de>
Subject:  Re:  installpkg

John Poltorak wrote:
> 
> More from Holger:-
> 
> On Wed, Nov 20, 2002 at 02:08:50PM +0100, Michael Zolk wrote:
> > On Sun, Nov 17, 2002 at 01:25:56AM +0100, Andreas Buening wrote:

To solve the problems Holger pointed out I wrote a long proposal how
I think the installpkg and other tools should work. It's at the bottom
of this posting. If you can find any further leaks in the installation
mechanism, please, tell me. If this has been fixed I might be able to
add the new directories to the FHS. ;-)


[snip]

> It does not make sense to have more than a single "core" package - you
> need every file in each such package somewhere somehow. Rather, you
> would introduce obscure dependencies if you have, say, core packages
> containing "sed" and "grep" and "sh" and only replace a single of them -
> result might be that no depending script will run any longer. No:
> the core package is "essential" and contains matching versions of
> all the three utilities, and whenever someone coins a new version
> of one of the "essentials", a matching set of all them must be issued.
> (Note the example is weak, because typically these three utilities
> are not too intertwined but it explains the point).

To simplify maintainance every source package like sed, grep, gawk
is one UnixOS/2 package. 


> > > SCRIPT {PREINST|POSTINST|POSTDEL} scriptname
> > > At least the POSTINST scripts can be sh scripts. Where are these
> 
> No. Simple case: what happens if you want to postinstall or deinstall
> ux2_base. You cannot rely on /bin/sh being around that time. So you
> have already one exception from the rule. How many more are maybe
> there? If /bin/sh is allowed, why not perl, tcl, python, lisp ...?
> It revolves around the basic idea: "behave always as if you have
> a naked OS/2 system" or in other words: "assume that your current
> installation of UnixOS/2 is incomplete or defective" - there must
> be a way to continue without removal of everything and starting over.

It should be possible that files can be installed and removed at any
time ot matter whether /bin/sh is there or not. Installations scripts
won't be executed if the UnixOS/2 Core packages aren't installed.


> > > scripts stored? How do you avoid name collisions?
> >
> > The scripts are copied to /var/lib/unixos2/scripts/. The scripts there
> > are named <pkgname>.postinst<number>. The <number> at the end is used so
> > that it's possible to have more than one script of the same type.
> 
> And to add: Number is to be taken as a sequence number, i.e.
> <pkgname>.postinst1 is to be run after <pkgname>.postinst0.
> No particular sequence can be easily determined concerning
> <pkgname1> and <pkgname2>, though. Don't even attempt to consider
> some explicit or implicit ordering - catch 22 alert!

I guess, I have a (more or less) solution for this. See below.


> > > Is it possible to execute a single command like
> > > "install-info --info-dir=/usr/share/info /usr/share/info/foo.info"?
> > > About every package requires a line like this for its .info file.
> >
> > At the moment only when you put it in an install script.
> 
> I don't see this as a mandatory feature at the moment, because we
> can split a package <foo> into <foo-basic> and <foo-man> and <foo-info>
> if we really want to give the user the opportunity to decide whether
> he wants to have on have not inforeader docs or man pages installed.

And finally you end up with <foo-ps>, <foo-dvi>, <foo-nls-french>,
<foo-nls-russian> and so on. Sorry, but that's not maintainable.
If the file is part of the package it is installed. Period.
If the user doesn't like french or chinese message files he is free
to delete them but don't expect that everybody splits every package
into single files. For the .info files: If the makeinfo package is not
installed then obviously the .../info/dir index files can't be updated
but that's all. That's the user's problem. The UnixOS/2 installation
tools should print a warning at this points and that's it.


[config files and other stuff]

> And if you deinstall "base" package, it is expected to delete also the
> files it has created. The deinstall logic, however, has to respect the
> table of dependencies: don't allow deinstallation of "base" as long
> as any installed package still 'REQUIRES base'. "ux2_base" is implicitly
> required to every other package: another reason for Occam's razor not to
> multiply "core" packages.

And what do you want to do if e.g. /bin/sh.exe has a bug and must be
replaced? Uninstall 200 other packages until you're allowed to uninstall
the sh package, then install the new sh package and the 200 other
packages? Or do you want to suggest to replace /bin/sh.exe by hand?
This might work for a single file but not if you have to replace more
files. And it's not the idea of having a packaging system.
No, if you want to uninstall a package you must be allowed to do so,
any package, even if it's /bin/sh.exe. If you did it then the UnixOS/2
system is in an undefined state and you must be able to install/uninstall
other packages but no POSTINST script will be executed until you've
reinstalled /bin/sh.


The following describes how I think the UnixOS/2 installation process
should work.
Especially, I'd like to know whether it's okay for you, Michael.
Please, don't bash me, if some directory name got different from
what we said before. It's a huge document and I might have got lost
somewhere. ;-)

#############################################################
(1) The UnixOS/2 Distribution
The UnixOS/2 Distribution is a set of software packages that set up a Unix-like
file system structure on top of the OS/2 operating system.

The FHS defines the locations of files in the UnixOS/2 tree.


(2) The UnixOS/2 Core Set
The UnixOS/2 distro is divided into several sets of packages. One of them is
the UnixOS/2 Core Set.

A package is part of the UnixOS/2 Core Set if and only if one of its files
belongs into /bin, /lib or /sbin. 

All packages of the UnixOS/2 Core Set have to be installed, otherwise the
state of the UnixOS/2 system is undefined.


(3) The UX2_BASE package
ux2_base is a special package of the UnixOS/2 Core Set that contains all
administration tools that perform the installation, maintainance and
uninstallation of all UnixOS/2 packages.

All administration tools are implemented in REXX.

The administration tools work regardless of the current state of the UnixOS/2
system. The only exception is if unzip is not available. In that case the
package files can not be unpacked.

The installation of packages that rely on the installation of other software
can not be completed and is delayed until the required software has been
installed.

[footnote: You can install and uninstall packages even if essential tools
like /bin/sh are not available (because they're implemented in REXX).
Why? Assume there is a bug in /bin/sh.exe so that sh.exe has to be replaced.
The idea of having packaging software means that you don't do the replacement
by hand. This means you must be able to uninstall the (old) sh package and to
install the (new) sh package at any time. This also means that between the
uninstallation of sh.exe and the reinstallation the UnixOS/2 system is in
an undefined state which means no installation scripts will be executed.]

All UnixOS/2 packages have an implicit dependence on the UnixOS/2 Core Set.

[footnote: This means no installation scripts can be executed until the
Core Set has been installed.]

Currently there are three administration tools: installpkg, removepkg
and ux2-update. All of them are installed in /bin.

All administration information that is needed to install, maintain or
uninstall packages is stored in /var/lib/unixos2 or subdirectories thereof.

No other program may ever access or modify data in /var/lib/unixos2 or even
rely on the existance of specific files there.


(4) Package Format
UnixOS/2 packages are compressed data files that contain files and
maintainance information.

UnixOS/2 packages are in zip format and have the extension ".zip" or ".ux2".

Package files contain the following information:
- The files to be installed. All files that belong to the package are stored
  in the according subdirectories of the zip archive, i.e. if "foo.exe" has
  to be installed as /usr/bin/foo.exe then its full file name in the zip
  archive is also /usr/bin/foo.exe. Files in the root directory of the zip
  archive are never installed.
- PKGINFO: This file in the root directory of the zip archive contains the
  information that is necessary for installation. PKGINFO is used by
  installpkg.
- COPYING (optional): This file in the root directory of the zip archive
  contains license information and is not installed.
- README (optional): This file in the root directory of the zip archive
  contains some information like "If you can read this somthing went wrong.
  please use installpkg" and is not installed.
- All other files in the root directory must be specified as so called
  Installation Scripts in the PKGINFO file.


(5) installpkg
installpkg is used to install packages. It works regardless of the current
state of the UnixOS/2 system and independent of any other UnixOS/2 packages
with the only exception of unzip that is absolutely required for installation.

installpkg performes the following actions on any package:
- reads the PKGINFO file
- does some version checking and warns the user if necessary
- checks package dependencies and warns the user if necessary
- runs removepkg to remove the older version of the package if necessary
- unpacks the whole zip archive temporarily into /var/tmp/install.tmp/<package>
- performs some checks whether PKGINFO and the unpacked files are consistent.
- stores PKGINFO as /var/lib/unixos2/pkginfo/<package>
- moves the PREINST|POSTINST|POSTDEL scripts to
  /var/lib/unixos2/scripts/{preinst|postinst|postdel}/<package>.<script>
- stores the installation info for ux2-update in 
  /var/lib/unixos2/install/<package> (the file might be empty).
- executes the PREINST scripts if any exist
- moves all files from /var/tmp/install.tmp/<package> to / if possible
  (if removepkg was called and failed due to locked files no file are moved
  to their final location)
- leaves all missing files for ux2-update


(6) removepkg
removepkg is used to uninstall packages. It works regardless of the current
state of the UnixOS/2 system and independent of any other UnixOS/2 packages.

installpkg performes the following actions on any package:
- reads the PKGINFO file from /var/lib/unixos2/pkginfo/<package>
- checks package dependencies and warns the user if necessary
- removes all files if possible (locked files are left to ux2-update)
- stores a list with all files to be removed in
  /var/lib/unixos2/uninstall/<package> (the list might be empty)
- if all files could be removed successfully the POSTDEL scripts in
  /var/lib/unixos2/scripts/postdel/<package>.* are executed.
- if all postdel scripts return with error code 0 they are removed.


(7) ux2-update
ux2-update is used to update the UnixOS/2 system. It works regardless of the current
state of the UnixOS/2 system and independent of any other UnixOS/2 packages.

When called without any special options ux2-update performes the following
actions:

(i) Final uninstallation of packages:
  If a file /var/lib/unixos2/uninstall/* exists:
  - read the file and removes all files that are listed there, this might
    require a reboot
  - if all files could be removed successfully the POSTDEL scripts in
    /var/lib/unixos2/scripts/postdel/<package>.* are executed
  - if all POSTDEL scripts return with error code 0 they are removed
  - /var/lib/unixos2/uninstall/<package> is removed
  - proceed with (i) until /var/lib/unixos2/uninstall/ is empty

(ii) Final installation of files:
  If a file /var/lib/unixos2/install/* exists:
  - checks for files to be installed in /var/tmp/install.tmp/<package>
    and moves all files to their final location (this might require
    a reboot)
  - removes the temporary directory /var/tmp/install.tmp/<package>
  - proceeds with (ii) until all files have been installed
  - removes /var/tmp/install.tmp

(iii) Final update of the UnixOS/2 system:
  - checks whether the UnixOS/2 Core Set is available and working,
    if this is not the case terminate
  - performs all operations from /var/lib/unixos2/install/<package>
    (register .info files, whatever) if possible. If some of the operations
    can not performed because the required subsystem is not installed
    (e.g. install-info) it prints a warning and proceeds.
    A subsystem "foo" is considered to be installed if
    /var/lib/unixos2/pkginfo/foo exist but
    /var/lib/unixos2/install/foo does not exist which means the installation
    for "foo" has been already completed.

[footnote: if a user does not want to read .info files or emacs .el files,
ps, dvi, tex, <insert your favorite here> then he is free to do so. The files
are put into their location, i.e. the user can change his mind later, but
these files are not registered, postprocessed or whatever they are supposed
to be done. This is no error but it will give a warning like "warning:
install-info not installed. install makeinfo if you want to read .info docs".]

  - checks all requirements for the package, if one is missing the final
    installation of the package is delayed and ux2-update proceeds with (iii)
    for the next package

[footnote: The UnixOS/2 Core Set is implicitely required by every package.
This means: if a POSTINST script needs e.g. perl then the final installation
is delayed until perl has been installed. This especially means: If one of
the UnixOS/2 Core packages is missing no POSTINST script will be executed
at all.]

  - executes all POSTINST scripts in 
    /var/lib/unixos2/scripts/postinst/<package>.<script> in an arbitrary
    order. Scripts with ".cmd" extension are executed by "cmd /c", all
    other scripts by "sh -c".

[footnote: If a script has to be called with options this can be handled the
following way:

----- script1 -----
#!/bin/sh
do_something
# call script2 with options
/var/lib/unixos2/scripts/postinst/<package>.script2 --with-some-options
-------------------

----- script2 -----
#!/bin/sh
# if the script is called without options just return 0
if test "$*" = ""; then exit 0; fi
# okay, we have command line options, we must have been called by script1
do_something_else
-------------------

This way it is guaranteed that both scripts can be executed in any
arbitrary order.]

  - if all POSTINST scripts return with error code 0 then
    /var/lib/unixos2/install/<package> is removed: the installtion
    of <package> has been completed.
  - proceeds with (iii) until /var/lib/unixos2/install is empty
#############################################################



Bye,
Andreas

-- 
One OS to rule them all, One OS to find them,
One OS to bring them all and in the darkness bind them
In the Land of Mordor where the Shadows lie.