> > You got the point, there are too many Unix PMS. > > Variation is not diversity. Variation increase > the > > cost of any engineering task. > > Oversight: there are so many UNIX software management > systems out there because not only do those account > for the packages on the system, they account for > specifics of the system they're designed for. > > What you're pushing for is an abstraction layer on > top existing package management systems. In my > experience that's not an optimal solution because the > abstraction doesn't account for system specifics, > which is unacceptable for any serious packaging that > needs to have a clean integration with the system.
Exactly. I (or we ?) can't really do much about existing variated Unixen. Except deal with it the best we can. For the record, I didn't invent this abstraction layer on top of PMS. My workplace and TWW Inc. did. HPMS is not an optimal solution from a PMS view. Add-on layer intruduce overhead. As long as this overhead bring more return than it cost then this is a good solution. The task of IT worker is to administrate a group of computer systems running different kind of OS. Oh, by the way the cost has to be low, the luxury of having different unix admin for different unix OS is gone. The new title is Unixen admin. > Not only would your abstraction layer not simplify > packaging, it would introduce some complex problems > as well, especially when it comes to development of > the package(s). > > For example, how would you account for system > differences between HP-UX and Solaris? IRIX? AIX? > Note that that is exactly what you're trying to solve > but it fails exactly where it's meant to help. Please look at this file, let me know if this answer your question about how to handle system differences. ftp://support.thewrittenword.com/dists/7.0/src/kde-3.3.2/sb-db.xml > > One big advantage is that [b]far more > > people > > > know how to use Linux RPM for building and > > > packaging[/b]. If OpenSolaris would use it, I'm > > sure > > > people would be interested in moving from Linux > to > > > OpenSolaris. In the long run, I believe the SVR4 > > > packages are old you really need to think about > > > replacing it. Like I said before, replacing SVR4 PMS is easy. The diffcult part is the dependecy built around SVR4 PMS over the time of years. The Solaris/OpenSolaris SVR4 PMS improvement project has to provide compatibility or small transistion. > > Solaris is looking to attract developers, not > necessarily Linux developers. > > Basically it boils down to the fact that most of > these people are just too lazy to sit down, 'warm up > the chair' and study the SVR4 / IRIX / HP-UX software > management subsystems. > Everyone seems to be concerned with the initial high > cost of learning, but I've yet to see SOMEBODY here > that takes into account the ridiculously low cost of > actually building packages for these systems once the > learning process is over and tools have been > developed. > > Example: it took me a good week before I understood > Solaris SVR4 software management subsystem. It took > me another day to write the tools to somewhat > automate and simplify the packaging process (once I > actually identified repetitive processes and sat down > to write the tools). > > I can package pretty much anything complying with Sun > / SVR4 in under 30 minutes now (time to compile > excluded, since that has to be done regardless of the > packaging system). > > Point: initial cost was relatively high, but long > term costs are very low. > Point: it pays to actually take the time to learn the > native packaging system. > Point: long term deployment costs are very low. > Point: RPM is being pushed out of pure lazyness to > sit down and learn something new (in this case, SVR4 > packaging). > Not many people know how to use different PMS to create different unix software packages. It is not a simple process and it wasn't fun. if one did this long engough, the homegrown automation script will be written to deal with different PMS will be written. I am sure next step of homegrown automation script will lead you to appreciate TWW HPMS. It is a very good candidate to be pushed as a standard becuaes it is well designed and GPL. I don't need to learn your autmoation script and you don't have learn mine. > > if OpenSolaris change its SVR4 PMS then I believe > it > > just shut the door to IT center and become a > > household hobby OS. I will change this view if > > Solaris (not OpenSolaris) switch its SVR4 PMS. but > > hen that time come, I will call in Sun Reps to > beat > > them up if Sun don't provide me a SVR4 to other > PMS > > transistion solution. > > Funny you should write that, since there are some > very vocal people here about how the focus should be > on the DESKTOP and not PRODUCTION, even though I > pointed out it's a 50:50 proposition. Solaris in PRODUCTION is the base to provide resouces for Sun 's attempt to gain DESKTOP market. Keep the base strong so Solaris can be offensive. And learn from your enemy, Windows use same PMS on both Windows 2003 and XP, right ? > > > Improvement ? yes. Change to other PMS ? no. > > Yes, probably not. And if push comes to shove, > `pkgadd` could be further improved, most likely with > very little if any impact on the consistency and > compatibility. > > > Don't like the content ? modify it. it is a wiki. > > anybody can contribute. not just me. > > I already corrected some of the text (in grammatical > sense, didn't change the content). Please feel free to change the content if you want to. As you can see I am not right candidate for writing documentation. look at makefile in http://en.wikibooks.org/wiki/OpenSolaris/Reference_Manual for wiki editing automation by command line tool. tj This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list [email protected]
