>Peter Tribble wrote: >>> Pkg(5) is still under development. It's rather unreasonable to suggest >>> that the unoptimized performance today, in development builds no less, >>> will reflect the final performance of the product at release. We have >>> more features to add and more optimization to perform. >> >> Pkg(5) has had considerable development effort expended on it. It's been >> released in shipping product for over a year. SVR4 has been neglected and >> left to rot. > >Peter, that is not true as someone else recently pointed out (e.g. >'turbo' packaging fix to SVR4).
Well, that was some form of hobby project for me. It took me 10 days to implement it (and many more weeks for "project overhead" and making sure that the code could run the package tests as the new SVr4 pkg commands will ignore you if you overwrite the contents file) This was the 3rd try to get the "contents" file out of the way. (The first one, using SQL, took many years of development, existed in some form of Solaris and was taken out because it performed poorly, specifically because using a SQL database used much more memory and failed to properly sort the contents file; I believe that using a standard DB engine is incorrect when the data stored and the way the data is retrieved are simple the second try was never delivered: I think the plan was to deliver a single contents file for each package) The way we implemented patches for SVr4 packages was wrong; but that could have been changed easily. Now I'm not even sure that removing class action scripts in pkg(5) is really a good idea, the additional burden created for each and every pkg is, IMHO, too large. Casper
