> > Why not adopt "rpm"? > > No way! IPS is awesome, it just needs more time to > mature.
As far as I'm concerned, a package system (whatever it looks like): * bundles a set of files that must be installed as a unit * provides sufficient information to in some sense verify package integrity (checksums are really too minimal, signatures would be much better) * provides for metadata sufficient to deal with dependency verification and other special needs; this should be extensible to handle future developments * provides for retaining sufficient metadata on installed packages to later verify their integrity after installation * provides tools to add, remove, and update packages * a comprehensive package system at least defines a mechanism whereby updates may be obtained. Considerations lending themselves to speed, efficiency, and ease of maintenance and updates also apply. There are probably other things I forgot. Most packaging systems currently in existence (not familiar with the SGI one cited previously) fall short in some way. Most _could_ be extended to largely do the job, IMO. In particular, starting at the pkg project page, I don't see an obvious path to anything that explains why SVR4 pkgadd format, if extended with additional metadata and signatures, would have fallen significantly short of what pkg hopes to accomplish. OTOH, I've heard that the pkg set of tools retains some backwards compatibility allowing at least some to most properly constructed 3rd party SVR4 packages to be installed (assuming I recall correctly). Anyway, I guess my point is that either (a) you start over (as pkg is doing), or you extend an existing format to handle all the special needs (zones, aware of zfs cloning shortcuts, etc). IMO, _if_ one were to extend an existing package scheme, notwithstanding whatever various Linux or *BSD distros may do, it would only make sense to extend the one that exists already on Solaris (SVR4 pkgadd format) rather than pick some other scheme (rpm, apt, BSD ports, pkgsrc, etc) on the basis of popularity, familiarity, targetted demographics or other such nonsense. You do _not_ abandon your base to pick up new folks. Since pkg is at least the dominant experiment, more likely the probable direction, and apparently backwards compatible enough for some/many/most purposes other than using packages _part_of_ existing SVR4 pkgadd based distros, that point is perhaps moot anyway. Having said all that, I'd be happier if there were a defined path of extension to a source-to-binary packaging scheme such that source packages could be created that could incorporate build recipes and be automatically transformed into binary packages. I gather that BSD ports, pkgsrc and srpms do those things to varying degrees of success. I don't say we should adopt one of those, but I don't see why we couldn't aspire to some such end-to-end functionality. pkgbuild does for SVR4 package building pretty much what rpmbuild does for rpms, and uses nearly identical spec files. Will there be an equivalent for IPS? This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list [email protected]
