From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Mon, 19 Aug 2002 04:35:26 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 303 ************************************************** Sunday 18 August 2002 Number 303 ************************************************** Subjects for today 1 Re: Some Ideas : IanM" 2 Re: Some Ideas : Maynard" 3 Re: Some Ideas : John Poltorak 4 Re: Some Ideas : John Poltorak 5 Re: Some Ideas : Andreas Buening **= Email 1 ==========================** Date: Mon, 19 Aug 2002 04:36:11 +1000 (EST) From: "IanM" Subject: Re: Some Ideas Hi Andreas >It has been rather quiet here for a while. May be it's now a good time >to start a discussion how the UnixOS/2 project should move forward. Great idea. >I apologize for the case some of the >problems have already been addressed or even solved. If they have, it would be nice if someone let the list know :) >requirements can't be met it might be suitable to start a UnixOS/2 project >at SourceForge. If we can get space at SourceForge, that would be great. >- flat and simple directory structure >- simple and unique naming scheme I'm starting a cleanup of os2site.com for unixported stuff at http://www.os2site.com/sw/unixport/ The file naming system on unixos2.com, to be blunt, sucks ! This will be rearranged, and have a lot more added shortly when I'm back home, then once I've figured out whats what with UnixOS2.org, I'll try to merge the various packages etc so there is one coherant directory structure, before I do this I will ask John & the list about preferences. It shouldnt be to hard to have two views of structures, ie, the UnixOS2 structure, and a structure similiar to the os2site one (but cleaned up), or even a totaly new idea put forward by list members ? >- write permissions for developers I can do this with the location of the present unixos2.com with individual FTP logins but SourceForge sounds like a much better idea, then we can have mirror sites. >2. How to build packages > >There isn't only the question which compiler flags/whatever are required to >build a package, but also which configure/whatever options are required/ >recommended/discouraged. We need a package build guide that contains all >this info: compiler flags (CFLAGS, LDFLAGS, ...), env. vars. (UNIXROOT, ...), >configure options (--prefix=xxx, --without-included-gettext, ...) and so on. >All exceptions from this rule (e.g. perl) have to be listed on the UnixOS/2 >website. This includes also the question _what_ has to be installed, e.g. >do we want a static or a import library /usr/lib/foo.a, do we want gzipped >man pages? OS/2 .INF files? And so on. This has been my biggest problem, also having to swap between different versions of utilities etc to end up with something that works. The other problem is recreating the working enviroment that someone else had when they created there port. >The next question is _where_ has it to be installed, e.g. do we want grep >or the file utilities in /bin or /usr/bin? /bin seems to be the default >on most unix systems. What about docs and other stuff of these packages in >/bin? Do we want their .info files also in /info and manpages in /man? I see no reason some directories cant be the same as OS/2, ie, I leave the etc directory in x:/mptn/etc for convenience, and having a seperate system and user bin directory is a moot point under OS/2, as they dont have seperate privileges BUT it can add in seperating dev binaries, and application binaries. I use x:/usr/bin, , x:/usr/sbin, x:/usr/dll to unify my unixos2 stuff. I do put all info and man files under man, as its pointless having the extra directory for this part. >I think a lot of people wouldn't like if UnixOS/2 would use lots of >directories in their root directory (e.g. bin, lib, share, info, man, doc, >libexec). Which is why I like the idea of x:/usr x:/usr/bin x:/usr/sbin (emx and development binaries) x:/usr/dll x:/usr/man etc Also programs like MySQL are already using the x:/usr directory structure. >- unixos2 specific stuff into /usr/unixos2 And thats a good idea. >3. Installation tools > >In order to make a "real" UnixOS/2 distro we need some tools for package >management. First we have to decide which file format we want to use: >a) zip (simple, everbody knows it, not as flexible as a "real" package > installer) I prefer ZIP personally, though I use to gz etc, its an OS/2 platform, so maybe we should standardise on WPI ? >summary: >- which package format (zip/tar.gz/rpm) zip (or WPI as it has full installation capabilities) >- install tools (preferebly REXX): ux2-install.cmd, ux2-update.cmd, > ux2-package.cmd, ux2-check.sh Sounds good. >5. Package maintainance > >Last but not least is package maintainance. We need people who do that stuff. >We need an distro maintainer (he has to keep track of the binary packages >and to release the distro), somebody who maintains the website, somebody who >writes and maintains the install tools, somebody who keeps track of all the >library stuff and of course some people who make the packages ready for >UnixOS/2. If no one else bites, I'm happy to maintain the site, and provide help via the website on procedures for creating the distribution packaging. >We need a priority list for packages that are important but have >no active maintainer yet. Not all of them need to be hardcore programmers. >If a package xyz once has been adapted to UnixOS/2 it is unlikely that there >will be severe changes to that software in the near future. This means >the job of the maintainer of xyz is basically to be on the xyz specific >mailing list (if there is any) and to test beta and pre releases of xyz >that are provided by the Unix maintainers of xyz. I'm happy to provide a testbed enviroment, I regularly trash HD's in trying new things, like bootable JFS :) Anyone know whats needed to get the ball rolling on SourceForge ? I'll be back home in two days, give me a few days to get reorientated and I'll start work on trying to update unixos2.com, accessing my PC remotely has nobs on it. I have also yet to go through the stuff from Ted. If anyone is interested in helping, download http://www.os2site.com/sw/filepile.zip and let me know if you see any unixported files that are in the wrong place. Also open to ideas about the directory structure under http://www.os2site.com/sw/unixport/ The main difference between os2site.com and unixos2.com is the file naming convention. Cheers IanM http://www.comkal.com.au/ "Notice how every new version of MS-Windows use's 4 times the amount of RAM than its previous version, and to run it, we then automatically multiply it by 4 again ? **= Email 2 ==========================** Date: Mon, 19 Aug 2002 06:46:35 -0500 (CDT) From: "Maynard" Subject: Re: Some Ideas John, >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 understand that there is no 'nix system on the planet with an /emx directory, but at the same time is there a 'nix system with the /emx contents?? If we need the contents of /emx, then it seems to me that /emx (or /sbin) tree is appropriate for OS/2 systems. In short, there is likely to be a short but important list of significant differences between OS/2 system and 'nix system FHS. --that part of FHS which deals with the distinction between single and multi user is irrelevant on OS/2 ?[/sbin]? --that part of FHS which deals with system boot is irrelevant [/boot] --free use of symbolic links is a challenge to OS/2 FHS; we don't want to encourage too many instances of multiple copies. --'nix habit of distributing scripts with hard coded paths needs to be acknowledged and accepted or patched. --and of course, the question of "what to do with EMX?" 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. Example: /bin = everybody needs these - file and shell utils /sbin = development tool tree /usr = runtime tree Perhaps some packages, notably EMX, would be more easily assimilated from root (/emx) rather than divided into the above. Submitted for collective consideration, -- Maynard **= Email 3 ==========================** Date: Mon, 19 Aug 2002 11:29:23 +0100 From: John Poltorak Subject: Re: Some Ideas On Sun, Aug 18, 2002 at 02:49:40PM +0200, Andreas Buening wrote: > Hello! > > It has been rather quiet here for a while. May be it's now a good time > to start a discussion how the UnixOS/2 project should move forward. > > I guess, all of us want to make the UnixOS/2 project becoming a success. > Therefore I thought about which problems may occur from the point we are > now to the point we can release an ISO image of the first UnixOS/2 > distribution. I'd like to see a lot of feedback. If you agree or disagree > or if you have other suggestions, please tell. If you have a solution to > one of the problems, please tell. If you want to help by doing one of the > outstanding jobs, please tell, too. I apologize for the case some of the > problems have already been addressed or even solved. > > > 1. Source Codes > > First thing we need is an organization of the source code. > summary: > - powerful ftp server > - flat and simple directory structure > - simple and unique naming scheme > - write permissions for developers > - if this is not possible start project at SourceForge 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. 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. In addition to SourceForge, I would want to have the latest release version of the UnixOS/2 distro at unixos2.com in a defined directory structure. > 2. How to build packages > > There isn't only the question which compiler flags/whatever are required to > build a package, but also which configure/whatever options are required/ > recommended/discouraged. We need a package build guide that contains all > this info: compiler flags (CFLAGS, LDFLAGS, ...), env. vars. (UNIXROOT, ...), > configure options (--prefix=xxx, --without-included-gettext, ...) and so on. I leave the choice of *FLAGS to the experts who understand the nuances of these things. It may well be that there is no setting which is globally correct and that the values may need to be set individually for each app. I would suggest that every UnixOS/2 app is build using an external gettext and regex and whatever other common libraries emerge. > All exceptions from this rule (e.g. perl) have to be listed on the UnixOS/2 > website. This includes also the question _what_ has to be installed, e.g. > do we want a static or a import library /usr/lib/foo.a, do we want gzipped > man pages? OS/2 .INF files? And so on. > The next question is _where_ has it to be installed, e.g. do we want grep > or the file utilities in /bin or /usr/bin? /bin seems to be the default > on most unix systems. I would prefer most common apps to go in /usr/bin, and only have sh in /bin with a copy in /usr/bin. > What about docs and other stuff of these packages in > /bin? Do we want their .info files also in /info and manpages in /man? > I think a lot of people wouldn't like if UnixOS/2 would use lots of > directories in their root directory (e.g. bin, lib, share, info, man, doc, > libexec). > Furthermore we need space for future extensions like a libc (I prefer /lib > for the basic survival dll's like emx, intl, regex) or some UnixOS/2 > related stuff (e.g. package management tools), e.g. /usr/unixos2. Using /usr/unixos2 should be discouraged. I want to eliminate /emx and /XFree86 from my system because they don't really belong and are likely to cause problems. If you think a /usr/unixos2 is required, then what would go there and what would be the location of a directory on Unix which had the equivalent function? I think we should try and stick with FHS wherever possible and even think about incorporating LSB (Linux Standards Base) if applicable. > Yet another thing is the libc itself. This is something we need to address and build up over time. Maybe we can start with regex and take it from there... > summary: > - standard build guide containing flags, env. vars, configure options > - _what_ has to be installed (static versus import libraries, ...) > - _where_ has it to be installed (/bin|/info versus /usr/bin|/usr/info) > - unixos2 specific stuff into /usr/unixos2 > - put all new Posix (or GNUish) functions into a ux2 (or better emx) library > > > > 3. Installation tools > > In order to make a "real" UnixOS/2 distro we need some tools for package > management. First we have to decide which file format we want to use: > a) zip (simple, everbody knows it, not as flexible as a "real" package > installer) > b) tar.gz (simple, less options than zip) > c) rpm (more complicated, more options) > d) something else (e.g. the corresponding debian tool?) > As I don't have experience with rpm and others I'd really like to know > what are its advantages and what are its disadvantages? We have been over this discussion many times and concluded that ZIP files were the most convenient for OS/2 users. I don't see any reason to change that. Of course, that doesn't preclude anyone providing a set of conversion tools so that an individual can use TGZ or WARPIN or anything else if they prefer. Personally, I think discussion about installation tools is a distraction at this point. I would prefer to encourage people, at least those on this list to build their own apps from source using the standard Unix methods of configure and make. Once we have the core distibution of UnixOS/2 building reliably by a significant number of people, then we should think about packages and how to distribute and manage them. As it stands now we will get wrapped up in endless discussions about whether 'prefix' should include drive letters. We should concentrate on empowering the end user to tailor their UnixOS/2 to their own specific environment, at least until a core system is in place. > How it works to create a (binary) package xyz: > ./configure --prefix=c:/new_prefix > make > make install > cd c:/new_prefix > ux2-package xyz > > How it works to install a (binary) package xyz: > ux2-install g:/download/xyz > ... install other packages ... > ux2-update > reboot (if necessary) I don't ever want to reboot to be able to use a package apart from addition of device drivers. On Unix, you just wouldn't contemplate rebooting after installing software. > ux2-check > > > summary: > - which package format (zip/tar.gz/rpm) > - install tools (preferebly REXX): ux2-install.cmd, ux2-update.cmd, > ux2-package.cmd, ux2-check.sh This has all been discussed, and a PKG tool has already been developed. What we need is standard base development system which I was trying to come up with over the last few months. > 5. Package maintainance > > Last but not least is package maintainance. We need people who do that stuff. > We need an distro maintainer (he has to keep track of the binary packages > and to release the distro), somebody who maintains the website, somebody who > writes and maintains the install tools, somebody who keeps track of all the > library stuff and of course some people who make the packages ready for > UnixOS/2. We need a priority list for packages that are important but have > no active maintainer yet. Not all of them need to be hardcore programmers. > If a package xyz once has been adapted to UnixOS/2 it is unlikely that there > will be severe changes to that software in the near future. This means > the job of the maintainer of xyz is basically to be on the xyz specific > mailing list (if there is any) and to test beta and pre releases of xyz > that are provided by the Unix maintainers of xyz. You have to design a self maintaining system as far as possible. Getting people involved as maintainers of part of a UnixOS/2 project is not easy. We have some great porters around who keep the likes of Apache, OggVorbis, Wget, Lynx and many, many other programs uptodate. They wouldn't want to feel under any obligation or constraint imposed by UnixOS/2. In effect, what you need is to take what has been ported and re-package it to comply with any UnixOS/2 standards, but don't expect the porter to get involved with it. IMV development of build scripts for every UnixOS/2 package should be sufficient to providing a self maintaining system. This is what my Unixos2 build system is supposed to provide at some point. It already works with a number of apps and should be easily extendible after a little refinement. > Any feedback would be really appreciated. :-) > > > 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: Mon, 19 Aug 2002 13:37:18 +0100 From: John Poltorak Subject: Re: Some Ideas On Mon, Aug 19, 2002 at 06:46:35AM -0500, Maynard wrote: > John, > > >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 understand that there is no 'nix system on the planet with an /emx > directory, but at the same time is there a 'nix system with the /emx > contents?? I accept that we need to have /emx in the short term but I would immediately move the include and lib dirs to /usr. A number of things in /emx/bin can be dumped since I don't see any need for maintaining any DOS based programs. In due course I would like to see most of gcc stuff relocated in /usr/lib/gcc which is where I think it belongs, although I would keep a copy of gcc.exe and some other emx binaries in /usr/bin. > -- > Maynard -- John **= Email 5 ==========================** Date: Mon, 19 Aug 2002 21:06:41 +0200 From: Andreas Buening Subject: Re: Some Ideas Maynard wrote: > > John, > > >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 understand that there is no 'nix system on the planet with an /emx > directory, but at the same time is there a 'nix system with the /emx > contents?? emx is our libc, i.e. this is what you can find as /lib/(g)libc.so or /usr/lib/(g)libc.so on Unix systems. > If we need the contents of /emx, then it seems to me that /emx (or > /sbin) tree is appropriate for OS/2 systems. We should provide an (optional) emx runtime package that installs the emx*.dll into /lib or /usr/lib so that UnixOS/2 can work as a standalone environment without any external 3rd party stuff. [FHS] > 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. It sounds reasonably to keep the runtime environment separate from the applications (and development tools). Putting the basic tools and libraries into /bin and /lib and everthing else into /usr would do the job. [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.