Sent from my iPhone On Dec 24, 2012, at 12:26 PM, Jim Klimov <[email protected]> wrote:
> On 2012-12-24 17:40, DavidHalko wrote: >> In the end, since we have SVR4 packaging, source is open, it is well adopted >> by ISV's, and user communities are aware of it - it seems to be suicide to >> follow any other path. >> >> We could be the group to drive open sourced SVR4 packaging, without breaking >> various licenses, since kernel linking is not required. There is very little >> needed to drive incremental improvement. Tack on dependence checking and >> move on... base it on a hack (OpenSolaris contributed code, OpenCSW, IPS >> code, whatever) - and move forward using a iterative model for improving >> things behind the scenes, since ISV's and Users won't care (as long as it >> works.) Adding SVCS support can be just a packaging convention, no code >> change. >> >> The longer we wrangle with this, the less relevant IPS is, as Oracle >> diverges. > > Well, a number of posters wrote that one good feature of IPS is a > strict meta-language to describe packaging. I guess in terms of > machine-based processing it is a good thing, and it was said there > are tools to convert IPS manifests into SVR4 (or other) package > descriptions. I think it may be possible to harness the facets > in order to generate several packages - i.e. base software, SMF > integration, "dev" (headers, etc.), docs, sample configs, etc., > perhaps even providing packages with correct executable/library > binaries for many architectures - from a single IPS description. > Apparently, some distros already do something like this to create > their package manager's rewraps of packages described in illumos > source gates. > > Also, IPS did make a loud point by restricting scripting, since > with all the local zones and other alternate BEs which might not > be currently booted (so as to run programs in their context on a > native CPU) correctly making a script for any and all cases may > be tricky. > > However, I think it was just a symptomatic aid - relieve the > symptoms and hope that the real problem goes away. It doesn't - > as examples of SMF workarounds have shown. However, the noise > also draws attention to the problem that old ways are no longer > the best always by default. While many crafty and creative coders > might make installers inside their packages which at some time > worked in their existing environments, eventual OS evolution > (such as introduction of zones and ability to push package > installation into a zoneroot from outside the zone or even > while it is not booted) might make old custom scripts plain > wrong. The packaging system should indeed provide some API to > hide the current OS's complexity and implementation and allow > the scripted customizations to be more portable between various > generations of OSes (at least, today's and unknown future's) > without need to rewrite the packages' scripts themselves to > support some new paradigm that the OS guys come up with. > That least-surprise approach to changes should help the ISV > adoption, and not require that their package makers learn > the bleeding edge development of illumos features every day. > > I think it would be beneficial to take some of IPS's sane ideas > and wrap them for "SVR4+" - for example, give common well-tested > methods to run pre/post/class scripts correctly. If the (Z)BE is > currently down - install the files and postpone these scripts > until next boot, then calling them in order of package installation > and applying packaged metadata (timestamps, owners, chmod) between > the preinstall and class and postinstall, as would be during live > installation. Provide methods to create new user/group accounts > (with preset and/or "available" ID numbers), including the cases > where the BE is down during initial installation (file copying), > and keeping in mind that these might (already) be defined in an > LDAP catalog or similar ID database - not in local files (though > that is folly for service accounts). > > Provide some differentiation between package update and complete > uninstallation (i.e. delete or preserve configs and logs, or make > diffs of old configs vs. old package's defaults and merge them > with new package version's defaults to provide updated configs?) > > So for things that IPS calls "actions" (other than dumb file > installations themselves) - user creations, file modifications, > service registration and startup - SVR4+ might in some way work > similarly so as to use the same logical descriptions as IPS. > > Maybe, technically, it would make sense to use the SMF or some > initscript structure to implement some of such features, but > that is a next tier of questions :) > > My 2c, > //Jim I kind of like the term SVR4+, Jim! Using class scripts in conjunction with documented conventions to deal with databases (SMF, user, password, services, etc.) is a place where SVR4+ class conventions can be a great help. Scripting can (and probably should) be reduced. If there is a SVR4+ class convention that updates /etc/services, the pre/post scripts could be scanned for references and force manual input check (i.e. The /etc/services file is being modified and the package is not using the class convention "inet-services" (see man page ...) - are you sure you want to continue?) I guess I prefer Guidance & Chinese Water Torture toward wholesale removal of functionality. :-) This type of approach may provide a way forward with gradually enhancing functionality while providing backwards compatibility. Use of newer class scripts, as documented in man pages, can facilitate the desire to reduce user interaction. I really love the (easy to parse) SVR4 "contents" file. 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. Some ISV's have abused the old short name convention by using stock ticker appended by a pseudo random number at create time. There is not much we can do about that, as the contents file gets filled with what seems like junk. An internal API expansion to lookup prerequisites gets tricky. With old SUNW stock ticker needed for backwards compatibility, yet new distro's needing their own naming, maybe common core items from Illumos get their own short name (since there are no stock tickers) - a package name alias database is needed, with a way of updating it, possibly programatically. Ultimately, the binary provider (the group compiling the released code, to unequivocally remove any concerns about linking) should probably be the owner of the short name. I can envision a distro provider who packages other items as defaults (twm, olm, olvwm, mwm, cde, lp, lpr, with their own "glue") but should not rename the packages provided "upstream" - but merely create customization packages that follow those former prerequisites. (The "upstream" providers should be sensitive to configuration files, so they can be tagged as "volatile", upon request from "downstream" ISV's, and get the version incremented.) This begs a federated "single version" of the metadata truth, with automated change control, reasonable response time from approvers who "opt in". Thanks, Dave http://svr4.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
