From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Sun, 25 Aug 2002 04:35:34 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 308 ************************************************** Saturday 24 August 2002 Number 308 ************************************************** Subjects for today 1 Re: FHS : Stefan Neis 2 Re: FHS : Stefan Neis 3 Re: FHS : Andreas Buening 4 Re: Some Ideas : Csaba" 5 Re: SourceForge : Maynard" 6 Re: SourceForge : John Poltorak 7 SourceForge : IanM" **= Email 1 ==========================** Date: Sun, 25 Aug 2002 00:18:53 +0200 (CEST) From: Stefan Neis Subject: Re: FHS On Sat, 24 Aug 2002, Andreas Buening wrote: > Unlike on Unix systems temporary files have to be stored into $(TMPDIR) > instead of /tmp. The environment variable ETC defines the location > of /etc. > Any comments? Why make porters' lifes unnecessarily hard and insist on the two points I cited above? I can live with two temporary directories and two versions of /etc shouldn't be a problem either. (When we get libemu, it might do that kind of thing automatically, but till then, I could easily live with $(UNIXROOT)/tmp and $(UNIXROOT)/etc or even /tmp and /etc on every relevant drive, though particularly the last version has quite a potential of getting annoying ... Regards, Stefan **= Email 2 ==========================** Date: Sun, 25 Aug 2002 00:22:30 +0200 (CEST) From: Stefan Neis Subject: Re: FHS On Sat, 24 Aug 2002, Steve Wendt wrote: > >The other Unix directories /boot, /dev, /mnt, /opt, /var have > >currently no meaning for UnixOS/2 and do not exist. > > most important: > /var/lock > /var/log > /var/spool Particularly the last one looks like most unix mailers are going to want to have that, or don't they in their OS/2-ports? > I think /usr/bin/perl is the standard place... And I think that's also where most perl scripts expect it, see the #!/usr/bin/perl line at the beginning... Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 3 ==========================** Date: Sun, 25 Aug 2002 12:32:34 +0200 From: Andreas Buening Subject: Re: FHS Steve Wendt wrote: > > On Sat, 24 Aug 2002 19:32:59 +0200, Andreas Buening wrote: > > >Unlike on Unix systems temporary files have to be stored into $(TMPDIR) > >instead of /tmp. > > Why $(TMPDIR) rather than $(TMP)? Are there Unix apps that look for that > variable already? Some GNU tools like the text utilities support this env. var. without any OS/2 specific code and outside of any #ifdef __MSDOS__ or similar statement, i.e. this extension works for all OS. Therefore I suggest to make TMPDIR part of the UnixOS/2 standard and not TMP or TEMP (which normally contain backslashes instead of forward slashes). Spaghetti code like const char *temp = getenv("TMPDIR"); if (temp == NULL) temp = getenv("TMP"); if (temp == NULL) temp = getenv("TEMP"); if (temp == NULL) temp = "/tmp"; is really unnecessary. Let's define that TMPDIR contains the temporary files. If it is not defined default might be "/tmp" but that's the user's problem not ours. > >The environment variable ETC defines the location of /etc. > > Do we really want to mix OS/2 and UnixOS2 ETC contents? Hopefully, there > isn't too much hardcoded to /etc, in that case. I don't know. I have no preference neither for $ETC nor for $UNIXROOT/etc. Let's just define it once and forever. There was a discussion about this topic some time ago but I don't remember the results. > >The other Unix directories /boot, /dev, /mnt, /opt, /var have > >currently no meaning for UnixOS/2 and do not exist. > > Some packages might want to install to /opt, but perhaps they should be redirected > to /usr/local. Not necessarily. If they are really _huge_ (e.g. OpenOffice) then we can put them into /opt or even onto another drive because not everybody's root partition may have enough space for several GB. We can add /opt to the UnixOS/2 standard as an (currently empty) directory that may exist on any drive. > /var could be important for things like logging, or maybe even other > things. Looking at the hierarchy on my Linux partition, the ones that might be > most important: > /var/lock > /var/log > /var/spool Okay, maybe we add also /var. > >(I recommend to add also the following shells and utilities to have > >them all at the same place:) > >perl > > I think /usr/bin/perl is the standard place... > > >The following files must be in /usr/bin, if the corresponding subsystem is > >installed: > >perl > > ... and you do have it listed here. ;) Yes, you're right. :-) If our "UnixOS/2 package installation, recovery and repair system" (TM) doesn't need perl we don't need it in /bin. > >If directories /lib or /usr/lib exist, the equivalent directories > >must also exist in /usr/local. > > Huh? Normally this is intended for 32 bit or 64 bit libraries (if the system supports both) but I think we'll have another usage for it: We still have to define which kind of libraries we want to install. I propose the following: .a libraries are statical a.out libraries, .lib are import OMF libraries. If there is anybody who doesn't like this scheme he is free to install static .lib or import .a libraries into /libstatic, /usr/libstatic or /libimport, /usr/libimport. Then he can use static OMF libraries by -L/libstatic -L/usr/libstatic and import .a libraries by -L/libimport -L/usr/libimport. 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 4 ==========================** Date: Sun, 25 Aug 2002 13:11:33 +0100 From: "Csaba" Subject: Re: Some Ideas On 18 Aug 2002, at 21:53, Franz Bakan wrote: > On Sun, 18 Aug 2002 14:49:40 +0200, Andreas Buening wrote: [snip] > >How it works to create a (binary) package xyz: > >./configure --prefix=c:/new_prefix > > Please NEVER use a drive letter in configure --prefix= > Because of this I had to manually patch my PERL-executables and dll's or You don't have to do that. IlyaZ's binary distribution of Perl 5.005_53 is compiled with F:\something , but it can be installed *anywhere*. You just have to set PERL_something in the environment. > my Window-manager wmaker.exe with some HEX-Editor before they were usable. [snip] A .sig ! A .sig! My kingdom for a .sig! **= Email 5 ==========================** Date: Sun, 25 Aug 2002 15:59:50 -0500 (CDT) From: "Maynard" Subject: Re: SourceForge On Sun, 25 Aug 2002 20:26:35 +0100, John Poltorak wrote: >A SourceForge repository would provide some unifying structure which is >what UnixOS/2 desperately needs. Maybe a dedicated CVS site would do the >same, but I have little knowledge of the capabilities of CVS. Speaking of CVS, OS/2 Netl at bs uses it; and looking at that I have to wonder, and here ask, what anybody knows about the [unix] tools project there, http://os2tools.netlabs.org/ -- Maynard **= Email 6 ==========================** Date: Sun, 25 Aug 2002 20:26:35 +0100 From: John Poltorak Subject: Re: SourceForge On Sun, Aug 25, 2002 at 10:23:44PM +1000, IanM wrote: > >5) There was a proposal to start a UnixOS/2 project at SourceForge. > > Total votes: pro: 1, contra: 1. As long as there aren't enough > > people who want to maintain a site at SourceForge I consider > > this idea as dead. > > I'm a SourceForge member, and I've looked into Registering a > New Project BUT, we need others to maintain parts. > > I like the SourceForge idea the more I think about it, it has a good > CVS Repository, bugtracker, Patch Tracking System, and Feature > Requests. I think the fact that SourceForge provides a ready made development infrastructure is useful. > But I to consider this idea as dead due to the lack of hands :-( Lack of hands will not devise an alternative infrastructure. Someone will still have to make it happen. > I'm still thinking about Johns ideas, ie, all SourceForge would > be needed for is to provide links to package source code > elsewhere, and have the unifying stuff and patches as part > of the one unixos2.zip package, ie, SourceForge becomes > the one package project called Unixos2, without all the source > and compiled packages, just the main package of patches, > directory structure creator, Package Code Converter, and a > regualarly updated list fo applications and URL's. A SourceForge repository would provide some unifying structure which is what UnixOS/2 desperately needs. Maybe a dedicated CVS site would do the same, but I have little knowledge of the capabilities of CVS. > It would be ideal to be able to download OpenWatcom, install > it, download unixos2.zip, install it, download the Application > source code, run unixos2 against the source code, compile > and run. As things stand OpenWatcom is a non-starter as far as UnixOS/2 is concerned. We are completely reliant on gcc. Hopefully this situation will change in the future, but I don't expect OWC to be an option for standard unix apps for at least a year. > We are slowly getting closer as more OS/2 specific changes > are added to by the source code maintainers of the unix > packages. > > No messin with wrong switches, hand editing long files etc. This is what I was trying to do with my attempt at putting together a standard developement tool set. It seemed reasonably successful for a number of people who tried building Perl v5.8.0 from scratch with the minimal effort... I did get as far as adding quite a few more apps, but one soon gets to a point where REGEX and GETTEXT are needed to make any progress. I would like to get them built from source, but REGEX requires GLIBC which is enormous, and GETTEXT appears to be unbuildable. > Cheers > IanM > > > The most exciting phrase to hear in science, the one that heralds new > discoveries, is not "Eureka!" but "That's funny ..." > -- Isaac Asimov -- John **= Email 7 ==========================** Date: Sun, 25 Aug 2002 22:23:44 +1000 (EST) From: "IanM" Subject: SourceForge >5) There was a proposal to start a UnixOS/2 project at SourceForge. > Total votes: pro: 1, contra: 1. As long as there aren't enough > people who want to maintain a site at SourceForge I consider > this idea as dead. I'm a SourceForge member, and I've looked into Registering a New Project BUT, we need others to maintain parts. I like the SourceForge idea the more I think about it, it has a good CVS Repository, bugtracker, Patch Tracking System, and Feature Requests. But I to consider this idea as dead due to the lack of hands :-( I'm still thinking about Johns ideas, ie, all SourceForge would be needed for is to provide links to package source code elsewhere, and have the unifying stuff and patches as part of the one unixos2.zip package, ie, SourceForge becomes the one package project called Unixos2, without all the source and compiled packages, just the main package of patches, directory structure creator, Package Code Converter, and a regualarly updated list fo applications and URL's. It would be ideal to be able to download OpenWatcom, install it, download unixos2.zip, install it, download the Application source code, run unixos2 against the source code, compile and run. We are slowly getting closer as more OS/2 specific changes are added to by the source code maintainers of the unix packages. No messin with wrong switches, hand editing long files etc. Cheers IanM The most exciting phrase to hear in science, the one that heralds new discoveries, is not "Eureka!" but "That's funny ..." -- Isaac Asimov