On Thu, Dec 27, 2012 at 2:27 PM, Jim Klimov <[email protected]> wrote: > 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.)
Some work has gone on, but it's incomplete. I find the new long package names to be no more descriptive than the old (and often less helpful, as they imply meaning and structure which does not in fact exist). And the organization - package boundaries and dependencies - still needs a lot of work. > 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). Define "compatibility". Binary? (Tricky, with S10, as the proliferation of open-source libraries drops you into the same dependency and compatibility issues that plague other OSes.) Difficult at the packaging and administration layer as so much has changed - claiming compatibility may be unsustainable. Having something that is familiar and works the same way should be possible, but that's a different claim entirely. > 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 Ugh. I hate this. Splitting a package into facets seems fundamentally broken. (If there's one thing that we can learn from Linux in this respect, it's that separate -devel packages exist only to make users lives miserable.) > 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 It's trivial to create the dummy packages, not obvious how useful they turn out to be. (Or even have the package installation create the package files; easy enough to do.) > would deliver no files except a dependency list to pull the new long > named packages. The biggest problem here is that the new packages have different package boundaries to the old, to the point that there isn't a simple mapping. Add to that the fact that a lot of dependencies are plain wrong, and you end up in dependency hell very quickly. > 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. Sort of. I'm not planning to expend much effort on a solver. Using dependencies to manage packages is a bad idea anyway. (In fact, managing packages is broken - you want to be managing applications and services, so put the intelligence there rather than into the underlying packages.) > 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. The one thing you really don't want to do is have two packaging systems active on the same system. So you would always have SVR4. It's trivial to create an SVR4 package from a repo though, even on the fly. > On 2012-12-26 22:43, DavidHalko wrote: >> I really love the (easy to parse) SVR4 "contents" file. > > +10 :) Yup. >> 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 :) All that's capable of being done within the pkginfo file. Some of that functionality has even been used by tools. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ ------------------------------------------- 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
