From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Sat, 23 Nov 2002 04:41:09 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 377 ************************************************** Friday 22 November 2002 Number 377 ************************************************** Subjects for today 1 Re: gzip/tar max path length : Andrew MacIntyre 2 Re: gzip/tar max path length : Lyn St George" 3 Re: REGEX.DLL : Andreas Buening 4 Re: installpkg : Andreas Buening **= Email 1 ==========================** Date: Sat, 23 Nov 2002 10:38:51 +1000 (est) From: Andrew MacIntyre Subject: Re: gzip/tar max path length On Fri, 22 Nov 2002, Lyn St George wrote: > Either way, it's a nuisance. The source code is in GTAR258, but as Andy > MacIntyre has mentioned that he is looking into star (which can handle > path/file names of 1024 characters) then I would rather offer to help out > with testing or whatever on that one. After some considerable cursing (mostly at the build infrastructure; ended up having to build Joerg's smake as well and that was nearly as painful), I have managed to build star 1.4.1. While OS/2 support is included (probably from the cdrecord port), it appears not to have been tested as I've had to synthesize a missing routine (readlink(2)) - I quickly hacked something up that results in symlinks being reported as not supported. At this point, I'm not overly happy with the result as to be useful IMO the hardlink and symbolic link cases need to extract copies of the files. More work is required for this. Interestingly tar 2.58 has trouble with the star tarfile which results in some files not being extracted (resorted to extracting on one of my FreeBSD boxes & using zip to get it back to OS/2). While star might end up working, the command line interface is just a tad different to GNU tar. I find the differences awkward after using GNU tar (standard on FreeBSD) for a long time, and this might be enough for me to go cold on star. If someone wants a copy of my experimental binaries to alpha test, let me know & I'll email a ZIP. -- 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 2 ==========================** Date: Sat, 23 Nov 2002 15:31:24 +0000 From: "Lyn St George" Subject: Re: gzip/tar max path length On Sat, 23 Nov 2002 10:38:51 +1000 (est), Andrew MacIntyre wrote: > >If someone wants a copy of my experimental binaries to alpha test, let me >know & I'll email a ZIP. I'll test as far as I'm able to. - Cheers Lyn St George +--------------------------------------------------------------------------------- + http://www.zolotek.net .. eCommerce hosting, consulting + http://www.os2docs.org .. some 'How To' stuff ... +---------------------------------------------------------------------------------- **= Email 3 ==========================** Date: Sat, 23 Nov 2002 16:34:39 +0100 From: Andreas Buening Subject: Re: REGEX.DLL John Poltorak wrote: > > On Fri, Nov 22, 2002 at 10:55:46PM +0100, Andreas Buening wrote: > > John Poltorak wrote: [snip] > All I am trying to do is build it for myself, and ensure that anyone is > able to do so using a standard set of tools, rather than something which > is unique to an individual developer... Okay, then add -lunixos2 to LIBS for compiling. > > > I would like to put together some scripts for building some basic apps, > > > and don't think it justifies grabbing glibc which is around 70MB or more > > > when you only want around 10kB. > > > > Sure. If you just want to _use_ the regex functionality you > > can use unixos2.dll. > > Is the source for this available? Sure. http://unix.os2site.com/sw/pub/source/libunixos2/.zip. 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: Sat, 23 Nov 2002 20:35:21 +0100 From: Andreas Buening Subject: Re: installpkg Michael Zolk wrote: > > On Sun, Nov 17, 2002 at 01:25:56AM +0100, Andreas Buening wrote: [snip] > Hmm... the more I think about it... :) The only Linux distro that I *really* > know good enough, Debian, seems to do it in a similar way. First all packages > are unpacked, when the files are in place the packages are configured. > > It would only be necessary to delay the configuration for all the stuff > that's in /bin, for everything else ux2-update could be called directly by > installpkg. > > > Because of that all install scripts can rely on every tool that > > is in /bin. I.e. sh or even sed scripts are allowed but perl scripts > > are not (because perl is in /usr/bin). > > This set of "essential" packages should be kept as small as possible. > Furthermore, it's important to choose an install method that makes life > easier for package maintainers. It would be good to get some more input > on this issue. Some other thoughts about this topic: We have: files to be installed, install scripts to be executed, *.info files to be registered (would be too oversized to prepare a script for just one line), normal scripts to be updated (absolute path names with drive letters have to be changed to take care of UNIXROOT). The installation procedure should support: Normal installation (run installpkg followed by ux2-update): - files of a package are installed - install scripts of the package are executed - *.info files are registered - normal scripts are updated Global reconfiguration (run "ux2-update --reconfig"): - files are already in place: nothing to do here - install scripts of all packages are executed again => install scripts can't have command line arguments (would be too difficult to store this information) - *.info files are registered again (just a "for %i in (*.info)", needs no additional information - normal scripts are updated again (for the case UNIXROOT has changed) => List of all this scripts must be stored somewhere. preinst scripts are executed BEFORE the files are in place, i.e. they must be executed by installpkg itself. ux2-update needn't even know of them. postinst and postdel scripts are executed AFTER the files have been installed (removed), i.e. they must be executed by ux2-update. Job of installpkg: - Consistency check of the package, version control - Install the files - If some files can't be installed (locked files, whatever), leave them to ux2-update (might require a reboot) => these files must be stored at a place where ux2-update can find them. And: ux2-update needs the information which package these files belong to so that ux2-update knows when a package installation has been succcessful. => store them temporarily in /install//... - Tell ux2-update what it has to do for which package. => write a small file /var/lib/unixos2/install/ for installation and /var/lib/unixos2/uninstall/ for uninstallation that contains the absolute paths of all install scripts to be executed for this package, all *.info files and all normal scripts that have to be updated. Job of ux2-update: - Install all remaining files (locked files, whatever) from /install/, this may require a reboot. - remove the /install/ directory - Check /var/lib/unixos2/install/* and perform all necessary updates for those packages. - remove the /var/lib/unixos2/install/* files. Btw, I'd prefer not to use /install. It's just another root level directory. /var/tmp/install might be a better solution for this. Okay, to summarize how a package installation works: 1. The user runs "installpkg foo". installpkg searches for the package, performes some consistency/version checks (however, at the moment we don't need such highly sophisticated stuff). 2. installpkg checks whether the directory /var/tmp/install/foo/ already exists. If yes => abort: cannot proceed package is already being installed => run ux2-update to finish the previous installation or remove that directory manually. 3. installpkg checks whether the file /var/lib/unixos2/install/foo alread exists. If yes => abort: same reason as 2. 4. Create /var/tmp/install/foo and unpack the .zip file into it. 5. Move all files from /var/tmp/install/foo/* to /*. If one file cannot be installed leave it here for ux2-update and print a warning. 6. The user runs installpkg for any other package he wants to install. 7. The user runs ux2-update to finish the installation. ux2-update looks for subdirectories in /var/tmp/install. It finds /var/tmp/install/foo and tries to install the remaining files. This might require a reboot. 8. As soon as /var/tmp/install/foo contains no more remaining files ux2-update removes that directory. 9. ux2-update reads its installation instructions from /var/lib/unixos2/install/foo (which might be empty). All instructions are executed. After that the instruction file is deleted. The installation has finished. The subdirectories of /var/lib/unixos2: packages: contains the (renamed) PKGINFO files, used by installpkg and removepkg only. scripts: contains the (renamed) install scripts install. uninstall: temporarily used to store installation instructions for ux2-update lists: file lists of normal scripts, used by ux2-update only. Does it sound reasonably for you? 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.