Some more comments on packaging & dependencies... An academic discussion on a new open-package directory concept... On Sun, Jan 6, 2013 at 5:17 PM, Peter Tribble <[email protected]>wrote:
> 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. > Solaris 10 Update # should be the goal. Anything beyond that is too much of a moving target. > > > 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.) > What is the reason for "-devel" packages under Linux? Is there a need for such a thing under another OS family? > > 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. Moving legacy files into new package names can be simply fixed... those new packages become dependencies of the legacy packages. Perhaps there could be a new flag for optional dependency - where optional dependencies are needed for strict compatibility, but those files were considered to be historic in nature. Moving a binary or library from one existing package into another existing package is suicide. Someone should allow that, in some type of governance position, unless the packaging version numbers both increment... and I don't know exactly how I feel about that. Dependencies could be moved, for alternate packaging models, into an external directory, where each packager can supply their pre-requisites. Maybe an NIS and/or LDAP "directory in the cloud". Each filename could have more than one packaging system reference defined. The SVR4 package name could become a pre-requisite for any packaging system, but multiple other package systems could then be identified in the external non-"contents" database file. All packaging systems would be required to map files back to the "contents" file a standard SUNW package, but new packaging systems would have the flexibility of an external network accessable database, which could be shared between all packagers. If new files are to be introduced, introducing them to an ILLU package prefix, instead of adding to the existing SUNW prefixed legacy packages, could be acceptable. I guess other distributions could get their own standard prefix, if it is not a stock-ticker, and someone in a position of regulatory power has not seen the same package prefix registered it for another downstream Illumos distro. > > 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.) > This could be an interesting thought. I don't know if this is what you mean, but let me make an attempt at what I think about application and service dependencies. Package dependencies could become automatic if done according to linked libraries. During the release phase, ldd's could be done against the binaries (automatically), provide a listing of ".so" files, those files looked up in the external universal NIS/LDAP directory for packages, and dependencies automatically mapped... so if people grab binaries and move them into legacy packages (i.e. lp, uucp, etc.) - the automatic dependency resolver would find it and update the LDAP/NIS directory. A similar thing could be done, looking for file names identified via "open" system call in binaries sh/ksh/bash script files, depending on how complex we would like to get? > > 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. If non SVR4 packages used an external global LDAP/NIS directory - multiple package systems could co-exist together... and even tell someone when a package from another non-SVR4 network package system was required, according to the directory. An option could be available to replicate that external directory during install (from network file share, tcp/ip url, cdrom, or usb key.) If an old package is available (uucp under SVR4?), an existing package is available (Java under [oracle]IPS), a new package is available (libreoffice under illumos-IPS... we can not use the same name, since Illumos IPS is a fork where Oracle owns the changes on their side) --- then the package front-end should be configurable to know now reference the available socket-based SVR4 repositories, Oracle IPS repositories, and Illumos IPS repositories. Federated Packaging should be the goal under OpenSolaris derivatives... with cross-packaging system compatibility (using paths and ld_library_path.) Thanks - Dave http://svr4.blogspot.com/ > > 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
