> pkgadd has been invented by AT&T engineers. This is known to me.
> It still > implements a lot of things > rpm and dpkg are missing. That is correct. I've recently done some RPM packaging and RPM is pretty kludgy when it comes to it - packaging is not as straightforward and as simple as it is with System V packaging. Advanced features like class installation scripts seem to be either missing from the design, or poorly documented. > We would need a few > additional features only to make > pkgadd better with respect to any feature. Like I wrote before on several occasions, the biggest technical flaw of System V packaging is that it does not support hierarchical namespaces which would provide for both making package metaclusters a reality, and would make Dennis's wish for unified packaging effort technically feasible. Another subtle but still major flaw is the fact that System V packaging tools aren't capable of automatic cleanup of obsolete delta files; that is simply left as a responsibility of the packager, which means there is no consistent and reliable way to do housekeeping between revisions. These are the things that are seriously hurting me as someone who does packaging day in and day out. I see the elegant and intelligent subsystems in IRIX and HP-UX and then I do Solaris packages, my bread and butter, and I hurt. I happen to know ways around it, but in doing so I'm pushing the System V packaging system to the limit, which can never be a good thing, and will most likely come back to bite me at one point or another. These changes require major surgery on the System V packaging subsystem. Who is going to do such a major undertaking? You? Me? On top of that, we'd have to go through the whole integration cycle, and for something as critical as a software subsystem, we're looking at a year of integration effort - just the bueraucratic part. We haven't even touched on the development effort yet. The ideal thing in my experience would be to contact SGI directly and see if they are willing to either license/opensource or just plain sell their software subsystem, especially if we consider that: a) IRIX has been discountinued, so sgi shouldn't be against giving it up b) IRIX's software subsystem understands and can handle System V packages, and integrates the information into his own software subsystem. This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
