well you could add a %post script that says:
echo Type 'service servicename start' to start you service.
But %post scripts should be silent.. It is better than prompting however.
The post script could also start the service itself, or check an env
variable to see if it should.
HTH,
James
James S. Martin, RHCE
Contractor
Administrative Office of the United States Courts
Washington, DC
(202) 502-2394
"Baz" <barry@xxxxxxxxxxxxxxxxxxx>
Sent by: rpm-list-bounces@xxxxxxxxxx
04/22/2004 12:39 PM
Please respond to RPM Package Manager
To: "RPM Package Manager" <rpm-list@xxxxxxxxxx>
cc:
Subject: Re: Installation Questions during the rpm installation
Paul,
Thanks for your wonderful inputs as always. I did get your point - RPM is
not designed to have any interaction with users.
Yes, most of the cases, for example, CATALINE_HOME or ORACLE_HOME can be
found if installed.
However, there are situation during the installation that are not the
same.
For example, at the end of the install, it is necessary for user to decide
if s/he wants to start up the application or not. How can you handle this
in
RPM installation?
Thanks
Barry
----- Original Message -----
From: "Paul Nasrat" <pauln@xxxxxxxxxxxx>
To: "RPM Package Manager" <rpm-list@xxxxxxxxxx>
Sent: Thursday, April 22, 2004 1:06 AM
Subject: Re: Installation Questions during the rpm installation
> On Thu, Apr 22, 2004 at 12:31:54AM -0700, Baz wrote:
> > Paul,
> >
> > Thanks for the answer, but i think i mislead you.
> >
> > Lets say, the installation checking the port available during the
> > installation. If the port is not available, ask for user input. Or,
lets
say
> > Oracle SID...etc.
> >
> > How can i ask for user inputs? If I cannot do it with RPM, then how do
you
> > guys approach this type of issues?
>
> RPM installations are by design not interactive, they aren't guaranteed
to
be
> run from a terminal (think synaptic, s-c-packages) or when a user is
present.
> Eg yum from cron. I'm pretty sure we covered this with you recently. To
> emphasise:
>
> YOU CAN'T AND SHOULDN'T EXPECT RPM TO BE ABLE TO INTERACT WITH THE USER.
>
> Remember, part of the strength of package management is inherently
policy
> based. Choose a system policy and stick with it (or adhere to that of
the
> distro you are targetting), don't try and double guess users in the
package,
> *sane defaults* that work on an unmodified system are fine - if users
have
local
> changes then they can expect to have to reconfigure stuff.
>
> Setting up some services is non-trivial and should require user
configuration -
> various packages ship with a sample config in %_docdir, as enabling by
default
> is undesired - dhcp springs to mind.
>
> Please explain your specific problem in detail - most things can be
achieved
> through other means, it seems you are starting with a solution rather
than
a
> problem:
>
> 1) provide a config file that allows configuration, put sensible
defaults
> based on the system. For JPackage tomcat we use different ports for
tomcat3/4,
> using a local port register consistent with our target installs. If a
user is
> running a different service on that port then they will have to manually
> configure, as it is marked %config(noreplace) then changes are preserved
across
> upgrades.
>
> 2) use variables - have a file that is sourced (eg /etc/sysconfig/oracle
or
> something in profile.d) to set environment variables. Changing
ORACLE_SID
in
> /etc/sysconfig/oracle could then be used by an init script or sourced
for
a
> user environment
>
> Paul
>
>
> _______________________________________________
> Rpm-list mailing list
> Rpm-list@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/rpm-list
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
