From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Sat, 31 Aug 2002 04:35:42 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 314 ************************************************** Friday 30 August 2002 Number 314 ************************************************** Subjects for today 1 Re: FHS : Andreas Buening 2 Re: FHS : John Poltorak 3 Re: Some packages : John Poltorak 4 Some packages : Andreas Buening **= Email 1 ==========================** Date: Sat, 31 Aug 2002 00:00:44 +0200 From: Andreas Buening Subject: Re: FHS Dave and Natalie wrote: [snip] > On Sat, 24 Aug 2002 19:32:59 +0200, Andreas Buening wrote: > > >3.4 /bin: Essential user command binaries (for use by all users) > > > >3.4.1 Purpose > >/bin contains commands that may be used by both the system administrator > >and by users, but which are required to maintain, install or repair an existing > >UnixOS/2 installation or to install or remove binary packages. It may also > >contain commands which are used indirectly by scripts. > > > > Another point here is that we could put /bin at the beginning of %PATH% > so utilities that have OS/2 equilavients could also go here. You mean e.g. "more"? We could at least recommend this. For some cases we'd better avoid name clashes, e.g. using "gpatch.exe" instead of "patch.exe" for the GNU patch executable. [snip] > Perl is usually in /usr/bin The question is what's usual? On most Unix systems shell utilities like perl (and also awk, bash, tcsh) seem to be in /usr/local/bin. We have to define once and forever where these tools have to be found because they'll be hardcoded in lots of scripts like #!/somewhere/perl. Btw. what do you think about docs in /usr/share/{man|info} (FHS compliant, but requires ./configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/man for _all_ packages.) versus /usr/{man|info} (not FHS compliant but we can drop two extra configure options)? [snip] 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 2 ==========================** Date: Sat, 31 Aug 2002 12:27:55 +0100 From: John Poltorak Subject: Re: FHS On Sat, Aug 31, 2002 at 12:00:44AM +0200, Andreas Buening wrote: > > Perl is usually in /usr/bin > The question is what's usual? On most Unix systems shell > utilities like perl (and also awk, bash, tcsh) seem to be in > /usr/local/bin. We have to define once and forever where these > tools have to be found because they'll be hardcoded in lots of > scripts like #!/somewhere/perl. I would put perl.exe in /usr/bin and the rest of the perl distribution in /usr/lib/perl. > Btw. what do you think about docs in /usr/share/{man|info} > (FHS compliant, but requires > ./configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/man > for _all_ packages.) > versus /usr/{man|info} (not FHS compliant but we can drop two > extra configure options)? What is the problem with using the available configure options? If they are available, I think we should use them and comply with FHS. I don't see any reason for not doing so. > 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. -- John **= Email 3 ==========================** Date: Sat, 31 Aug 2002 14:55:15 +0100 From: John Poltorak Subject: Re: Some packages On Sat, Aug 31, 2002 at 03:33:40PM +0200, Andreas Buening wrote: > 3. The libc. Where do we want to put libc extensions like > GNU regex (or GNU glob)? Giving each of them their own > dll provides just chaos. They should either go directly > into the libc (i.e. emx) or go into one single additional > dll (e.g. ux2.dll). > > Comments, suggestions, opinions? I would like to see an OS/2 version of glibc, but rather than porting the whole thing at once, I'd prefere to see it built up as when various libraries are required. As for DLLs, my preference would be for individual DLLs such as regex.dll. The alternative would be a constantly changing UX2.DLL which would invariably be a source of problems due to conflicting versions. I much prefer stability than a required weekly update which is what would happen if a single DLL was used for providing a wide range of functionality by a great many programs. > 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. -- John **= Email 4 ==========================** Date: Sat, 31 Aug 2002 15:33:40 +0200 From: Andreas Buening Subject: Some packages Hello! Some thoughts about some special packages: 1. gettext. I think we'll need two packages of it: One "normal" package that contains the whole stuff including locale info charset conversions via iconv and so on. And a "dummy" package that contains basically only a 4 KB intl.dll that does nothing. It's for people who don't need locale support or for boot disks or whatever. 2. iconv. Do we want to use Andrew Zabolotny's iconv that is very small and just a frontend for uconv.dll. Pro: it uses the native OS/2 nls implementation. Contra: it doesn't support all charsets all over the world. This might be no problem because nearly no program uses iconv directly (only via the gettext library). The other option would be to use GNU iconv. I propose to give iconv/2 a try because it uses the native OS/2 API for this. We can choose another name (iconv2) to avoid name clashes with GNU iconv. I propose also to install only static .a and .lib versions of this library (no .dll) because it's really rather small and just a frontend for uconv.dll. 3. The libc. Where do we want to put libc extensions like GNU regex (or GNU glob)? Giving each of them their own dll provides just chaos. They should either go directly into the libc (i.e. emx) or go into one single additional dll (e.g. ux2.dll). Comments, suggestions, opinions? 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.