From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Tue, 20 Aug 2002 04:35:27 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 304 ************************************************** Monday 19 August 2002 Number 304 ************************************************** Subjects for today 1 Re: Some Ideas : IanM" 2 Re: Some Ideas : Stefan Neis 3 Re: Some Ideas : Stefan Neis 4 Re: Some Ideas : Andreas Buening 5 Re: Some Ideas : Andreas Buening **= Email 1 ==========================** Date: Tue, 20 Aug 2002 18:33:45 +1000 (EST) From: "IanM" Subject: Re: Some Ideas Hi Maynard >>I want to eliminate /emx and >>/XFree86 from my system because they don't really belong and are likely to >>cause problems. > >What do you mean by /emx doesn't belong? I put my emx exe's in c:/usr/bin, and the dll's in c:/usr/dll, I cant see a reason to have them in there own directories, saves path space in config.sys as well. You are correct that they could just as easily site in sbin as system binaries. The other relavent parts go into c:/usr/lib, and c:/usr/man, and c:/mptn/etc, you can if you want move c:/mptn/etc to c:/usr/etc, and I now a few who have. >In short, there is likely to be a short but important list of >significant differences between OS/2 system and 'nix system FHS. As it should be, as OS/2 isnt nix, but as long as the enviroment works, with the minimum impact and greatest ease of use/setup. The REAL Important thing is that have some sort of standard that can be adhered to, different nix's differ in minor ways, so as long as OS/2 also only differs in "minor" ways, I think we can live with it. >--that part of FHS which deals with the distinction between single and >multi user is irrelevant on OS/2 ?[/sbin]? There are obviously logical differents which can be dealt with in a similar fashion to how Apache has delt with it. Something like a 90% adherance to some sort of popular Unix or Linux structure, BUT you will always need something to fix the other 10% simply because OS/2 isnt 'nux, see below re a config.os2 file or similar. >--that part of FHS which deals with system boot is irrelevant [/boot] Leave this as c:/os2/boot, as its OS/2, so yes, that part is irrelevant. >--free use of symbolic links is a challenge to OS/2 FHS; we don't want >to encourage too many instances of multiple copies. One standard library "set" is required, as John points out, this in conjunction with the OS/2 changes already being accepted into the code will/would be ideal ! >--'nix habit of distributing scripts with hard coded paths needs to be >acknowledged and accepted or patched. I can see this being addressed by running a program like unixos2.cmd, which would drill through the source and make the required changes. All you need to do is install the "unixos2" package, and the defaults would be written to a file (config.os2 ?). (Just thinkin aloud here) >--and of course, the question of "what to do with EMX?" If required, leave it in usr/bin or usr/sbin, and usr/lib. >Also, it is sensible to me that development and runtime environments, >including FHS/2, be separable; so that runtime systems do not have >development only tools; and that those tools required for development >can be extracted into FHS/2 independent of the runtime FHS/2 >directories. In theory (love that phrase), if someone has the development enviroment, and decide they nolonger need it, it should be a simple matter of deleteing the entire structure, and replacing it with the runtime version. Hm, that sounds dangerous, thinking about applications installed under usr/, howabout a simple script that lists the differences, and can then decied what needs to go to change the development enviroment to a runtime enviroment or visa versa. >Example: >/bin = everybody needs these - file and shell utils >/sbin = development tool tree >/usr = runtime tree Thats also acceptable, though I would still put at least /sbin under /usr/, code requiring shells hardcoded to /bin shouldnt be to hard to fix surely ? >Submitted for collective consideration, The pot has more ingrediants added, stir, let simmer, check the taste, add a bit more salt, maybe some spices etc, let simmer, and check again. Cheers IanM Men are liars. We'll lie about lying if we have to. I'm an algebra liar. I figure two good lies make a positive. -Tim Allen **= Email 2 ==========================** Date: Tue, 20 Aug 2002 22:08:03 +0200 (CEST) From: Stefan Neis Subject: Re: Some Ideas On Sun, 18 Aug 2002, Andreas Buening wrote: > Maybe. Maybe not. I don't know the real capabilities of rpm > or the debian installer. Let me put it like this: rpm really sucks. It's the kind of Windows-like "I know better than you what you want to do" tool which is driving me crazy (i.e. it's telling me all the time what I want to install first (even though I know I won't need it) and trying to convince rpm to not enforce such a requirement is always ending up in convincing me to just install what it wants (which means Virtual PC's "disk image file" is much larger than it needs to be, slowing my "Virtual Linux" down rather noticeably. :-( ). > > Please NEVER use a drive letter in configure --prefix= > > Because of this I had to manually patch my PERL-executables and dll's or > > my Window-manager wmaker.exe with some HEX-Editor before they were usable. > > It depends. The program has to consider $UNIXROOT. If it doesn't > any prefix will lead to problems. Therefore we need a build guide > which one has to be the default prefix (this might be c:/usr or > /usr) but also a list of all packages that need another prefix. Holger's master plan is that e.g. /usr/bin will be automatically "translated" to $UNIXROOT/usr/bin by LIBEMU, so no need for the program to consider $UNIXROOT (in the long run, at least). However, setting the prefix to c:/usr will or X:/usr or u:/usr (or whatever your favourite drive) will almost surely disable that kind of auto-translation, so it would be a good idea to get used to prefix=/usr. Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 3 ==========================** Date: Tue, 20 Aug 2002 22:23:46 +0200 (CEST) From: Stefan Neis Subject: Re: Some Ideas On Mon, 19 Aug 2002, John Poltorak wrote: > A number of things in > /emx/bin can be dumped since I don't see any need for maintaining any DOS > based programs. AFAIK, that relates exactly to emxfpemu (AFAIK, OS/2 doesn't work on any processor without floating point unit, so there's never a need to emulate one) and the loader programs emx.exe, emxl.exe, and emxd.exe which in total will save 200 KB or 0.something percent of the size of an emx installation. Big deal ... ;-) Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 4 ==========================** Date: Tue, 20 Aug 2002 23:05:35 +0200 From: Andreas Buening Subject: Re: Some Ideas John Poltorak wrote: > [snip] > My view of UnixOS/2 has always been that we should get OS/2 accepted among > the Open Source community as a legitimate host for running Open Source > Software. If we can do this then building OS/2 versions of apps will not > require jumping through various hoops as it does now in many cases. If we > accept this starting point then we don't really need much space for > source code, only pointers to where the original source is located. In theory, yes, in practise we need space for the sources, current and earlier versions and, of course for the binaries, again current and earlier versions. Most packages are of the order of 1 MB for sources and about the same for the binaries. 50 of them and we easily exceed the 100 MB limit (for the current version only), even if the sources for OS/2 and Unix are the same and if you use only links to them. > All we > really need are any required patches for an OS/2 release of an app. In > some instances we can build OS/2 versions straight out of the box. > Invariably, we will require an OS/2 build script. In effect all we need is > space for patches and a build script which is a trivial amount of space as > far as source code goes. > > I have long suggested that UnixOS/2 should be a SourceForge project and > did try to get one started, but my request for this was rejected, probably > because I didn't provide sufficient information. IMV SourceForge provides > a great many features which would simplify the management of such a > project. What exactly are the benefits for us? I've looked at their website and they seem to have an 100 MB limit per project which means we'll need our own ftp server in every case. They provide cvs but we don't have one single source package we have dozens of them, every of them gets a few changes, the results are submitted to the "official" maintainer and that's it. cvs make sense if there is more than one single person working on the same sources at the same time. I think we'll be happy if we can find at least one maintainer for a package. Bug tracking software? I can't speak for other people but if I get two bug reports for one single package that's a lot. For this I don't need any bug tracking. Mailing lists? Web forums? If we want to split this mailing list we don't need SourceForge for it. I'm sorry, but from my point of view we don't need SourceForge. However, if you (especially some people who have experience with SourceForge) know some other benefits I'll be glad to listen. [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 5 ==========================** Date: Tue, 20 Aug 2002 23:06:14 +0200 From: Andreas Buening Subject: Re: Some Ideas Stefan Neis wrote: > > On Sun, 18 Aug 2002, Andreas Buening wrote: [praise song about rpm] Okay, then we'd better forget rpm. Do you know anything about the debian installer? > > It depends. The program has to consider $UNIXROOT. If it doesn't > > any prefix will lead to problems. Therefore we need a build guide > > which one has to be the default prefix (this might be c:/usr or > > /usr) but also a list of all packages that need another prefix. > > Holger's master plan is that e.g. /usr/bin will be automatically > "translated" to $UNIXROOT/usr/bin by LIBEMU, so no need for the > program to consider $UNIXROOT (in the long run, at least). > However, setting the prefix to c:/usr will or X:/usr or u:/usr > (or whatever your favourite drive) will almost surely disable that > kind of auto-translation, so it would be a good idea to get used > to prefix=/usr. a) Nobody knows when his libs will be finished. If it's June 2005 then it will be too late. We cannot wait for this. b) I don't like the approach that I won't be able to use e.g. grep from a REXX script just because both use different incompatible file systems. From a) follows that we have to deal with plan B (== emx) which means we have to implement some kind of handling for the hardcoded paths. We can define a standard 1) we have to compile all packages for c:/usr and the program has to check c:/usr and $UNIXROOT/usr for that file, or 2) we have to compile all packages for /usr and the program has to check for $UNIXROOT/usr only. 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.