On 2012-12-24 18:48, Garrett D'Amore wrote:
I'd love to see a minimalist distro take up the call to "post process" the illumos-gate IPS manifests into SVR4 packages. (I significantly think that *reverting* the packaging back into the old SVR4 packages is a huge mistake -- I know some others have done this in the name of compatibility with S10 -- I think Joerg and Peter have both trod that path. Long descriptive package names, and the reorganization that we have got in our current manifests is not something I would just throw out.)
Well, compatibility with S10 (and older) is a huge bonus for a distro that would seek to be "the opensource replacement for legacy Solaris" and would be easy to update into (i.e. via LiveUpgrade at best). HOW this can be done is another matter. Continuing my speculation about possibilities of SVR4 package generation according to source IPS manifests, including splitting of IPS packages (facets) into several SVR4 packages to install only needed subsets and/or to match the legacy packaging boundaries, I believe it is rather trivial to make dummy packages with old names (SUNW* and a few others) which would deliver no files except a dependency list to pull the new long named packages. I thought of several other variants, the second best is adding native support for alias package names - this seems cleaner, but unlike the dummy packages, new code will require work, testing and might bring a new incompatibility against old code/format :) The solution with dependencies, to be practical, requires a quick and automatic dependency resolver and installer - but this does not break any API (implementation detail) and is a goal per se anyway. Generation of these dummy packages can probably be automated from IPS manifests as well (I think there is a syntax for alias names) allowing a SUNW* dummy package to depend on several new long-name packages if required, or even to have several SUNW* dummies depend on a single long-name package if it now delivers all files that were previously separated into different packages. I think this, while not a universal solution, would cover most of the practical concerns about old and new package naming, especially for legacy-oriented distros (fresh installs won't be required to install these dummies, I guess, and can "live" natively with long named packages). An interesting twist might be to allow SVR4 packages to depend on native IPS packages (from networked or local repo) just in case. I'm almost certain that some uses for this can be found :) Perhaps, site-local configs and policy files could be distributed as seemingly the same SVR4 package for SVR4-based distros and zones, and then easily "pkg update"'d... On 2012-12-26 22:43, DavidHalko wrote: > I really love the (easy to parse) SVR4 "contents" file. +10 :) > When I am > having a difficult time with an OS or package issue - this is the > first place I go (with "grep" & "awk") to see where things are > supposed to be, which package a file came from, if there is another > version of a binary available, or even what a a proper file name may > be if I know some other details of a file. > > Using a similar formatted file for pre-requisites, package aliases, > package groupings, etc. may be helpful. The old format of package > names using "stock tickers" provides some benefit. +1 :) //Jim Klimov ------------------------------------------- illumos-discuss Archives: https://www.listbox.com/member/archive/182180/=now RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be Modify Your Subscription: https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4 Powered by Listbox: http://www.listbox.com
