Your line of thinking is almost precisely what I wanted to see from SVR4 evolution; the most urgent need being for the driver actions. But SVR4 *code* is a mess… take a look to see what I mean.
-- Garrett D'Amore Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Monday, December 24, 2012 at 9:26 AM, Jim Klimov 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 > > > > ------------------------------------------- > illumos-discuss > Archives: https://www.listbox.com/member/archive/182180/=now > RSS Feed: https://www.listbox.com/member/archive/rss/182180/22003744-9012f59c > Modify Your Subscription: https://www.listbox.com/member/?&; > Powered by Listbox: http://www.listbox.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
