Hello there,
I tried my luck with this question at linuxquestions.org and got a
couple of answers already.
In case you want to take a look at them:
http://www.linuxquestions.org/questions/linux-general-1/how-to-upgrade-running-apps-preferably-through-rpm-673813/
Cheers.
Adrián.
Adrián Márques escribió:
Thanks for your answer Greg. You were right; even opinion and
conjecture are helpful.
Fellow packager Tim Born also kindly shared his experience directly
with me (thanks Tim!), and with his permission I'm posting his
response to the list in order to share it with everyone else.
Is there anyone else that could provide any input on this?
As an extra comment, the app in question is not a daemon, it's
user-interactive, so stopping it in the %pre section prior to the
update is not an option for me.
Thanks.
Tim's email:
Hello Adrian -
I'm surprised the RPM for the application being updated does not stop
& restart the service daemon(s) as part of the update.
That was how I was taught to do things.
I suppose it's possible there are apps out there that can ride over
having their files being changed out from under them.
Not many of mine can. So in the %pre we check for an update and stop
the app, then in the %post we again check to see if this is an update
& restart the app.
Works well for us.
best
-tim
Greg_Swift@xxxxxxxxxxxxxxxxx escribió:
I apologize for insisting on this matter, but so far I haven't been
able
to find info on this anywhere. I've looked at tomcat's and openoffice's
spec files as examples of packaged java apps, but it doesn't seem they
take any sort of precaution when updating. Is it really not an issue if
the app happens to be running at the time?
In my experience I don't know that I've found a single web app that
seems
to be overly concerned with this process inside the rpms. We have some
internal java web apps, and I believe they just have "turn off x and y
services" listed in the update docs we distribute.
As for updating a database schema accessed by our app, I suppose we
could add that logic to the app itself and have it check before it
starts whether it should modify the database, but I find adding scripts
in the RPM much easier and I'd prefer any problems with the
modifications to come up the moment the update is applied and not
whenever the app is next started.
Once again, I haven't seen many that addresses this issue. Part of the
problem of including this inside the RPM is the db authentication
method.
I believe most apps I've seen require you to install the RPM, and
then run
either a schema import or update script. I've thought about this on
my own
though and have decided that I like the concept of my application being
aware of its own schema, and managing the changes to the db itself (i
realize that this can in and of itself be a bit of a nightmare, but
then so
is making schema changes via package managers). Remember, I haven't
tried
implementing it.
I'd really appreciate any comments you could give me on this, whether
they are direct answers, indirect tips on how I could find this
info, or
kind advice to go RTFM (as long as you tell me which FM in particular
that would be :) )
I was avoiding commenting on this because I didn't have any solid
answers
for you, but at this point I guess opinion and conjecture is enough
since
no one else has commented.
enjoy
-greg
_______________________________________________
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
