[Yum] Showing rpm messages before rpm completes

[Les Mikesell]

On Mon, Jan 6, 2014 at 2:18 PM, John Dennis <jdennis at redhat.com> wrote:
> On 01/06/2014 02:51 PM, Les Mikesell wrote:
>> On Mon, Jan 6, 2014 at 11:38 AM, James Antill <james-yum at and.org> wrote:
>>>>> Is there any sort of best practice (I'm likely missing) for
>>>> accomplishing this sort of thing? I'd like to do things in a typical
>>>> manner, but I'm finding yum to be somewhat prohibitive in this area.
>>>
>>>  If you have something like database initialization, that requires
>>> user interaction ... it's common to just not do it at rpm time.
>>
>> How is the rpm supposed to communicate to the user that those
>> additional steps are needed?   Or, if it set up a new user to own the
>> contents, to provide the credentials to access it?
>
> The typical approach is to provide a setup script. The RPM does not run
> the script, just installs it. You reference the script and the need to
> run it in a README or INSTALL which the RPM also installs in the doc dir.

So users are expected to hunt for a README or INSTALL file for every
RPM they install?   I guess that explains the relative obscurity of
linux.

> If the setup steps are Red Hat (e.g. Fedora, RHEL, CentOS, etc.)
> specific then it's typical to name the file README.redhat.
>
> BTW, installing a software package seldom means configuring it to run.
> Installing is just installing, configuring is something else. Why?
> Because it's not unusual to install a package because it *might* be used
> later.

'Not unusual' is an odd thing to design defaults for...    Having a
'silent' option for the automated case might have been nicer.
Although you'd normally want to run yum to automate rpm even if you
could control yum interactively.

> The idea is the sys admin will make a conscious decision to
> configure and enable it. There are exceptions to the "install does not
> mean configure and run" rule, but I'm guessing you don't fall into this
> small class of packages.

Two that pop to mind are OpenNMS (from their own repo), where you need
to configure the java version to execute first, then manually run an
install step that checks for sql schema changes and applies them, and
backuppc (from EPEL) where a web user login needs to be created.
They do spew some hints about what to do next to stderr that are easy
to miss.   I think the apt-packaged version of backuppc does something
interactive to set up the web user password instead of just telling
you to run htpasswd at a command line yourself which is at least a
little more friendly.

-- 
   Les Mikesell
      lesmikesell at gmail.com