https://bugzilla.redhat.com/show_bug.cgi?id=2275304
Kamil Dudka <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?([email protected] | |) --- Comment #3 from Kamil Dudka <[email protected]> --- (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 -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
