Please see inline ... On Tue, Aug 21, 2012 at 8:55 PM, Joerg Schilling <[email protected]> wrote: > Moinak Ghosh <[email protected]> wrote: > >> It has been a long time, approx 5yrs since I last touched that code and >> difficult to recollect everything. Some tidbits I do remember: > > Thank you for your reply... > > >> 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. > > The data base has a lot of related concepts and the mportant thing to know is > that you first need to install the new package and then remove the old one. > There are reference counters and there is the fact that files are actually > only > removed when they have not been changed since the install of a to-be-removed > package. If there are problems with upgrades, I expect only small problems in > special as the package system supports versioned package installs. What I need > to check is what happens after MAXINST upgrades have been passed. > > What really is missing is the knowledge that a package is never than another > one and support for versioned dependencies (although there is a parser for > versioned dependencies already). > > >> 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. > > This is just a result of bad management inside Sun. > > I was really shocked to see the mess here, but this is something we can dix > and > I already started to write standard scripts to be used via include. > > The worst package here is SUNWcsd that should not include a static > name_to_major table. > > >> 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. > > Isn't this something that should be be fixed with pkgserv? > > I am able to install the whole ON base within less than 2 minutes over the > network, even though the packages are compressed via xz -9. It would be of > interest to know what time you get..... > > Could you please fetch: > > > http://download.berlios.de/pub/schillix-on/packages/pkgs-schillix-on.txt > > and follow the instructions. Note that this works directly with pkgadd over > the > network.
Will check ... > >> 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. > > See above, I cannot see and real problem with it today. > > >> 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. > > The packages system was created in 1982, so it is 30 years old. But not the > time of creation matters... Age will not matter if the code is properly maintained. How old is the Solaris kernel ? SVR4 code has been badly maintained due various factors including bad management that I do not like to discuss here. > >> Adding missing pieces to SVR4 will mean first and foremost a repo >> mechanism, package management and seamless upgrade support. > > I need to add a base URL for automated network installs, but this does not > seem > to be hard to do. > >> 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/ > > Thank you, I'll read this later.... > > >> 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! > > I had some discussions with Dagobert Michelsen from opencsw already and he > seems to have a lot of knowledge in this area on the svr4 package system. It > seems that we just need to make the important decisions now and could > implement > most of the code later. > > >> 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. > > Well, if we look at what existing OpenSolaris based distros use, there only > seems to be IPS and from what I've seen with IPS during the past 2 years, I > don't like to use it. The worst case happens when I try to install a new package in my OpenIndiana installation after a gap of say one month. Several minutes just to get a pkg of a few hundred KBs in size over my 8MBps link. Most of the time is spent in plan creation I think. > > On the other side, why take something completely new if there is experiences > with a mature existing system? > My point is the mature system is missing very key pieces like package management. Working on adding it will amount to re-doing a solved problem. My preference is to use a ready-made tested solution. In addition I simply do not like the SVR4 code. You can call it personal bias, but that is how it is. I want SVR4 support but in a different way. I want to focus my efforts to better explore Pacman and see how to add Solaris platform and SVR4 support there. There are multiple options including an alien kind of converter: http://joeyh.name/code/alien/ So one can auto-convert from SVR4 format to Pacman format. 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
