Hi Folks, I have been giving some thoughts to the way the BeleniX package repository should be structured and the way we should go about using a proper packaging solution. I am listing some observations below. Comments/suggestions are more than welcome :)
* Let consider the dependency list of SUNWfirefox: cat /var/sadm/pkg/SUNWfirefox/install/depend P SUNWcar Core Architecture, (Root) P SUNWkvm Core Architecture, (Kvm) P SUNWcsr Core Solaris, (Root) P SUNWcsu Core Solaris, (Usr) P SUNWcsl Core Solaris, (Shared Libs) ... ... Now my question is why do we need these dependencies on the core system ? It is not conceivable by any stretch if imagination that it will be possible to run Firefox without having SUNWcsr installed ... much less boot the system! So what purpose do these dependencies serve other than causing trouble ? Any auto-dependency resolution mechanism will try to pull down updated versions of these packages while trying to update Firefox from an recently updated repository thus screwing the running system. Can't we simply assume the base OpenSolaris system to be present without having to explicitly specify dependencies on it. * Having the above enables us to have a clear separation between the base operating system and layered software on top. Thus I can choose to perform a software-update without having to upgrade my base system, or update an individual software package and dependencies without the packaging system trying to pull down an updated libc! I should still be able to do a dist-upgrade to perform a complete system upgrade in a new boot environment. This is additional flexibility to the user. * However the above scenarios do not preclude brokenness. It is possible that a new layered software package needs a new version of a base system package, say for example hal. Updating to than new version without updating hal in the base system will cause breakage. This scenario can be tackled by extending the dependency mechanism with the ability to express version-specific dependencies like in RPM. Thus trying to update pkgx where pkgx.depends: hal >= 10 for eg. will fail if installed hal version is 9. This is because hal is part of the base system and updating the base system requires a dist-upgrade. * While doing a dist-upgrade it should be possible to specify a target release to upgrade to. This means that the BeleniX package repo should maintain separate or tagged repositories per release and micro-release. Of course disk usage can be controlled via effective usage of ZFS clones. There are several approaches to going about getting these things done: 1) Stick to SVR4 and build wrapper utilities to get these features - moderate efforts but potential obsolescence since OpenSolaris is moving away from SVR4 and the packaging format is kinda creaky. 2) Migrate to IPS and extend it - quite a bit of effort needed. In addition to above we need to add in more stuff like on-disk package file format support, full mirroring (including manifests), ability to remove packages from a repo, do not use timestamp-based versioning, web-based repository browsing and package searching etc., and several more things. 3) Use Dpkg and Apt from Nexenta's port. This gives a wealth of features and readymade solutions with maybe small effort needed to put in some tweaks. This is not aligned with what the OpenSolaris community is converging on - IPS. A lot of new OpenSolaris features will be implemented in the longer run centering on IPS. So in the longer run Dpkg might need more effort and will be a completely diverged but well-known solution. >From my opinion I see merit in approach #2 even though it needs quite a lot of effort. I do also see merit in #3 but then we get diverged. Comments, Opinions ? Regards, Moinak.
