[OpenIndiana-discuss] complaint about dovecot in sfe IPS not starting.

[Jim Klimov]

On 2013-02-25 14:54, Dmitry Kozhinov wrote:
> I am not accusing anyone, but just trying to understand:
> Why not make a package so that it would run out-of-the-box?
>
> When you buy a car, imagine that engine would not start unless you:
> - Kick right rear tire;
> - Open and close trunk lid;
> - You name what else...
>
> Maybe those who know what-to-do (to simply get a package running) feel
> themselves gurus, which is cool, but obviously making things go this way
> condemns the great OS into extinction.


The steps you've described are more akin to the need to pick correct
dependencies and rule out possible conflicts of several implementations,
as also happens to be needed - and indeed, such packages should be
fixed.

There are many other packages which can work "as is" either because
they need no custom configuration (i.e. an office suite), or because
they can use some system configs (default domain name, UNIX user ids)
and thus not require customization - although that is often needed
down the road. For example, a web browser might need proxy settings
if it doesn't consult http_proxy envvars, or trust to your corporate
CA root, and those settings are too custom to distribute in a common
repository (though in a corporate setting you might like to maintain
your own repo with common settings baked into packages).

And there are programs which require configuration. You can't go around
that - an LDAP server or a database needs to know its root suffix name
and unique administrative login credentials, its clients - also. Even
getting to work something as simple as an NTP client might require that
you provide your preferred NTP servers (i.e. ones in your LAN, or from
your nearby ISP); relaying from sendmails through a common single relay
requires you to set the DS option (aka smarthost), etc.

What *could* be done better in such cases is provision of SMF manifests
to integrate the services, including dependencies on config files - so
that if the service fails to start, "svcs -xv" can better show you why.
And also I've just recently raised an RFE to have a common svcadm option
to enable/restart/clear an SMF service instance in one command and not
caring about the service's previous state.

There are many examples of programs which include separate steps of
installation (which provides files onto a filesystem) and configuration
(which customizes the setup and enables services). Often the config
programs can implement a "silent" mode, so that they don't ask questions
interactively but rather read prepared answer-files (usually made by
saving another config session's results into a special format).

Remember that the packaging paradigm, especially with IPS, considers the
delivery of packaged software into non-executing OS images (i.e. into an
inactive local zone), and any configuration would run only in this zone
context when it boots. This is assumed more reliable than the preinstall
and postinstall scripts in SVR4 which were written before local zones
were invented and never changed since then. Some packages now use some
hackery like SMF services which do the same tasks to configure the
custom installation and self-destruct or hide. I am not sure how well
this works along with de-configuration and removal of packages (i.e.
preremove/postremove in SVR4 terms) and how upgrades are differentiated.

HTH,
//Jim

PS: At least, in many cases we are beyond DIY car sales, where you get
boxes of components, a purse of tools and documentation - and build
your car just like you would assemble an IKEA bed. Though, this is not
yet always the case in IT (nor is it generally possible for each and
any package).

Being, apparently, from Russia you should know that this is not very
much a joke - a reform of the car industry did once suggest such 
distribution of cars: factories don't do a very high quality job
anyway, so people often have to take new cars apart and rebuild them.
Distributing boxes of pieces would save everyone time and money ;)

//Jim