Date: Wed, 10 Dec 2003 02:19:50 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 264 ************************************************** Tuesday 09 December 2003 Number 264 ************************************************** Subjects for today 1 Re: UnixOS/2 distro : Michael Zolk 2 CVS flowcontrol patch for testing : Andrew Belov" **= Email 1 ==========================** Date: Wed, 10 Dec 2003 00:34:29 +0100 From: Michael Zolk Subject: Re: UnixOS/2 distro On Thu, Dec 04, 2003 at 11:56:02PM +0100, Andreas Buening wrote: > What I think is important: A readable documentation of how these tools > are used and what they basically do (aka a manpage) and a documentation > of how the installation process works which means some kind of > specification. In this way other people could rely on this and some > general behaviour can't change between different releases. The > specification shouldn't be a novel, just a basic outline. ;-) The first part of this documentation would be the pkginfo.5 man page where I tried to summarize the results of the discussion on this list. I think there are two areas that are important when thinking about a specification. The first is the format of the PKGINFO file which is the only "interface" to the installation tools that package maintainers see. The second is the package database which should only be accessed by the installation tools. Once a program follows these (non-existing) specifications the inner workings of these tools are not so important :-) I tried to think about what to do when the format of the PKGINFO file or the package database changes, but it's too late today... > There's also a lot of error handling necessary. E.g., installpkg.cmd > doesn't check whether rexxutil and ux2util were found. OK > No idea, but I think we won't need a real database. Since it might > be too time consuming to read in hundreds of pkginfo files every time > e.g., some package dependencies have to be checked. Therefore, a file > that contains all package dependencies could be suitable. Also a file > that contains name and origin of all files and directories that have > been installed might be useful. It should be no problem to create these files since installpkg has the necessary information anyway. The files could look like this: bar: foo xyz libexample foo: abc def ... where the package "bar" depends on packages "foo", "xyz" and "libexample" etc. /usr/bin/foo: foo /usr/share/man/man1/foo.1 : foo /bin/bar: bar ... This should allow for relatively quick lookups (at least I hope so :) Michael -- http://www.borashop.de **= Email 2 ==========================** Date: Wed, 10 Dec 2003 02:46:23 +0300 (MSK) From: "Andrew Belov" Subject: CVS flowcontrol patch for testing At ftp://os2ports.com/incoming/cvs11204.zip, there's a test version of CVS v 1.12.0.x (based on a quite outdated 20030414 snapshot). This interim release is distributed with a particular intent to test a rather important patch for handling large repositories over :pserver:. From some medieval versions, CVS provided a "pserver flow control mechanism" to keep the memory consumption within reasonable limits. A pserver should not consume more than 2 megabytes per client connection when compared to CVS operating in rsh/local mode. However, this facility has been broken for years. Presently, :pserver: memory consumption depends on the total size of files being checked out. It may grow twice as large (e.g. exceed 1 gigabyte per client for a 500M project, as if there was a memory leak). In extreme cases, OS/2 will starve memory and the system may fail. This usually happens under some of the following conditions: - A single directory concentrates the majority of the whole repository (e.g. the whole tree is 550M large, but 500M reside in a single subdirectory without subtrees) - The pserver operates in Zlib (-z) compression mode - The CPU is fast enough, the network connection is slow enough to cause a congestion, and the network output relies on DMA (i.e. the NIC driver does not keep the CPU busy while sending data). The patch proposed in this release restrains the memory usage by (1) checking for overruns on per-file basis, rather than per-directory basis, (2) applying the necessary workarounds to recover the flow control in "-z" mode. Now, the per-connection memory usage should be expected no more than 8-10 times the size of the biggest file in repository (a historical rule-of-thumb for CVS), and no longer dependent on the overall size of project/module/repository. I'd like to hear any comments from those who extensively employs pservers under OS/2. I intend to make a more refined implementation of this patch (to account for GSSAPI/Kerberos layers) and submit it to the mainstream CVS codeline later on.