https://bugzilla.redhat.com/show_bug.cgi?id=2275304 Kamil Dudka <kdudka@xxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(msuchy@xxxxxxxxxx | |) --- Comment #3 from Kamil Dudka <kdudka@xxxxxxxxxx> --- (In reply to Miroslav Suchý from comment #2) > ># record timestamp > >echo -n '>>> ' > >date -R > > This looks like development stuff. Definitely should not be in final rpm. Is there a better way to log what happened in %post? The same RPM package can be installed multiple times and the log is appended each time. We need an admin-friendly way to distinguish each run of %post in the log file. > ># this only takes an effect if PostgreSQL is running and the database exists > >pg_isready -h localhost && %{python3_sitelib}/osh/hub/manage.py migrate > > This is a discouraged practice. Could you please point us to the corresponding guideline? > You never know how big the DB is. I saw migration that lasted several hours. Yes and the DB on the internal OSH instance has always been migrated this way. As far as I know there is no timeout for executing %post. > You do not want to block rpm upgrades because of db upgrade. Or even worse, fail because of that. Why? 1. We want application upgrades to run unattendedly where possible. 2. If we fail to upgrade our RPM-packaged application, we want to know about it rather sooner than later. > This should be separate step, outside of rpm. It could be done as a separate step. But what advantage would it bring to the OSH admin? Why should they manually do something that can be done fully automatically during the installation? -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component https://bugzilla.redhat.com/show_bug.cgi?id=2275304 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202275304%23c3 -- _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
