Forgot to cc list on the replies.
On Tue, Aug 21, 2012 at 7:54 PM, Moinak Ghosh <[email protected]> wrote: > On Mon, Aug 20, 2012 at 10:17 PM, Joerg Schilling > <[email protected]> wrote: >> Moinak Ghosh <[email protected]> wrote: >> >>> > [...] >>> come to is that I do not want to touch the existing SVR4 codebase. >>> This comes from past experience with the codebase @ SUN. In one >>> short word it is horrid. I do not wish to waste my time on that. >> >> If you know real problems in the SVr4 pkg format or implementation, feel >> free >> to shre them with others. >> > > It has been a long time, approx 5yrs since I last touched that code and > difficult to recollect everything. Some tidbits I do remember: > > 1. SVR4 does not have the concept of package upgrade. So if for eg > pathnames are changed in a new package release old one has to be > uninstalled and new version reinstalled to do a clean update. However > it is not possible to do this with core system packages, so it needs > wrapper scripts or custom class-action scripts. So pathname changes > in core OS pkgs may also require system config updates. There is no > support for doing these other than through custom wrapper scripts. > > 2. The concept of action scripts is a powerful one but with no control > it creates a complete mess. For eg every team in SUN that ever provided > a driver had their slightly different variant of the driver > install action > script. It was a mess of action scripts all around. > > 3. I remember a team member fixing a customer escalated bug when he > figured out that a particular supposedly binary search for looking up > pathnames was actually doing a linear search - some messy code. > > This only points to the age of the codebase, 25yrs approx. Old and > somewhat clunky with a whole bunch of commands and libs. > > 4. The approach of keeping all pathnames in a single large text file > (/var/sadm/install/contents) is suboptimal. While this was updated > by Casper Dik sometime back there are other such things. Limitations > had only been patched over and over without any significant cleanups > or re-writes to fix old design limitations. > > SVR4 had excellent concepts, in fact was state of the art 25yrs back. > The concepts are still awesome even by today's standards but > implementation leaves much to be desired. > > Adding missing pieces to SVR4 will mean first and foremost a repo > mechanism, package management and seamless upgrade support. > Once again trying to re-do solved problems. I was forced into the > unfortunate wheel re-invention for an earlier BeleniX version because > we did not want to touch IPS with a barge pole and we had no choice > in the short term but to develop Spkg: > http://moinakg.wordpress.com/2008/11/22/the-belenix-package-manager/ > > > http://belenix.svn.sourceforge.net/viewvc/belenix/trunk/spec_files/ext-sources/spkg?revision=175&view=markup > > http://belenix.svn.sourceforge.net/viewvc/belenix/trunk/spec_files/ext-sources/spkg_mod.py?revision=395&view=markup > http://moinakg.wordpress.com/2008/11/22/the-belenix-package-manager/ > > It had all the useful features and brought in at least one concept that > "I dare say" was discussed within the IPS team later, without attribution > of course. However it was never intended to be a full fledged replacement > before people jump to find flaws in that. > It took about 6 months part-time effort for a single person to develop > compared to the 3-years of elaborate intricate complex wheel re-invention > with the intention to solve world package hunger and even do, surprise > surprise Windows package installation! > >>> Supporting SVR4 correctly will require some effort but I think it is >>> doable getting a cleaner implementation in the process and avoiding >>> re-inventing wheels. >> >> The result from my investigations is that it is easier to get the few missing >> parts into the SVR4 package that to make the reinvented wheel (IPS) work to >> my >> needs. > > I want to give a wide berth to both IPS and the existing SVR4 > "implementation". > I actually respect SVR4 as a concept but am not interested in doing > anything > with its current codebase. > > Regards, > Moinak. > -- > ================================ > http://moinakg.wordpress.com/ _______________________________________________ belenix-discuss mailing list http://mail.opensolaris.org/mailman/listinfo/belenix-discuss http://groups.google.com/group/belenix-discuss
