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/21175430-2e6923be
Modify Your Subscription:
https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4
Powered by Listbox: http://www.listbox.com
