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
