> 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. 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. > 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. 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). > 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. > 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). This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
