Re: [opensuse-factory] RFC: configuration files in /etc

Am Dienstag, 4. Juni 2019, 08:32:23 CEST schrieb Bernhard Voelker: Well, I've done something directly related minutes ago, and will show, that your general solution is able to mitigate the issue (which is a good thing of course, hence thumbs up from my side), but I want to outline the workflow, that has to be done for the cases beyond your proposal. Running a local GitLab installation from home:darix:apps since about 2 years (now on 15.0). I went though a lot of ups and downs due to package complexity. Most of the times, where automatic updates fail (rpms install correctly, but the gitlab-ce-update fails with some obscure traceback...), installation produced a couple of .rpm{new,save} files. Let's not discuss weal and woe of this specific package, Darix is doing a tough job here, but what's needed to address the cases, that your proposal will not fix, and how this could be provided with a real example. GitLab upgrade from 11.11.0 to 11.11.2. $ gitlab-ce-update Hoping into the basedir within env production 3a51abc8a15d4d06511e9b7331b07175a8ec235ef9c9f818e31b39b3ee314ff7 Gemfile.lock 04112ef0c0e80c1be2093ea3f004770a2ae8daa5afccec364d95fa38a18d189d Gemfile Running rake WARNING: Nokogiri was built against LibXML version 2.9.7, but has dynamically loaded 2.9.9 rake aborted! NameError: uninitialized constant Gitlab::ProxyHTTPConnectionAdapter /srv/www/vhosts/gitlab-ce/config/initializers/hipchat_client_patch.rb:4:in `<class:Client>' /srv/www/vhosts/gitlab-ce/config/initializers/hipchat_client_patch.rb:3:in `<module:HipChat>' /srv/www/vhosts/gitlab-ce/config/initializers/hipchat_client_patch.rb:2:in `<top (required)>' /srv/www/vhosts/gitlab-ce/config/environment.rb:6:in `<top (required)>' /usr/bin/rake.ruby2.6:23:in `load' /usr/bin/rake.ruby2.6:23:in `<top (required)>' /usr/bin/bundle.ruby2.6:23:in `load' /usr/bin/bundle.ruby2.6:23:in `<main>' Tasks: TOP => db:migrate => environment (See full trace by running task with --trace) Oh well... $ find . -name \*.rpm\* ./gitlab.yml.rpmnew ./config/application.rb.rpmnew ./initializers/hipchat_client_patch.rb.rpmnew ./initializers/lograge.rb.rpmnew ./initializers/1_settings.rb.rpmnew ./initializers/sentry.rb.rpmnew ./initializers/peek.rb.rpmnew ./initializers/sidekiq.rb.rpmnew ./locales/doorkeeper.en.yml.rpmnew ./locales/en.yml.rpmnew ./routes/group.rb.rpmnew ./routes/project.rb.rpmnew ./routes/admin.rb.rpmnew ./gitlab.yml.example.rpmnew ./routes.rb.rpmnew In the end, one have to go through all these, look at the diff, and either: a) accept the new version b) decide on the diff hunks case by case c) ignore/throw away the new version So, I would love to see an interactive mode in zypper, that shows the cases, that would create .rpmnew/.rpmsave files beforehand (ideally including the diffs), provides additional command line switch to make case a) default (dangerous), and if interactive decisions are enabled, go through every hunk and ask: apply, apply all ((case a) -> next file), keep, keep all (case c) -> next file), go to previous patch/pile, go to next patch/file, edit hunk manually. This would greatly improve the operational safety for complex configuration issues, that compliments your proposal. Done right, we wouldn't see any .rpm{new,save} files anymore, and could treat such as an unsolved issue. Hope not being off topic too much. Cheers, Pete -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org