Obviously, nobody can remember to manually run a program to check for .rpmnew every upgrade. Can zypper notify about this at the end automatically? The only reference I found googling "zypper notify about rpmnew" was [0] with a broken link to openFATE. Was it ever implemented? [0]: https://lists.opensuse.org/opensuse-features/2013-02/msg00022.html On 24/08/2019 09:44, Philippe Conde wrote:

Hello,

After zypper dup mariadb cannot be started. Replacing old "/etc/cnf" by "/etc/my.cnf.rpmnew" solves the problem. Regards

Dominique Leuenberger a écrit :

...

Please note that this mail was generated by a script. The described changes are computed based on the x86_64 DVD. The full online repo contains too many changes to be listed here.

Please check the known defects of this snapshot before upgrading: https://openqa.opensuse.org/tests/overview?distri=opensuse&groupid=1&version=Tumbleweed&build=20190822

Please do not reply to this email to report issues, rather file a bug on bugzilla.opensuse.org. For more information on filing bugs please see https://en.opensuse.org/openSUSE:Submitting_bug_reports

Packages changed:    PackageKit    fwnn    libetonyek (0.1.8 -> 0.1.9)    libreoffice    librevenge    libsrtp2 (2.1.0 -> 2.2.0)    mariadb (10.2.24 -> 10.3.17)    rubygem-sassc (2.0.1 -> 2.1.0)    shotwell (0.30.5 -> 0.30.7)    yum

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Saturday, 24 August 2019 18:16:46 ACST Oleksii Vilchanskyi wrote:

Obviously, nobody can remember to manually run a program to check for .rpmnew every upgrade. Can zypper notify about this at the end automatically? The only reference I found googling "zypper notify about rpmnew" was [0] with a broken link to openFATE. Was it ever implemented?

[0]: https://lists.opensuse.org/opensuse-features/2013-02/msg00022.html

[...]

This is one thing that apt (debian) does well - where there is a configuration file to be replaced or updated, it displays a prompt with the options to Overwrite with the developer's config, keep the original config, or display the changes/differences and choose between them. If apt can do it, why not zypper? -- ============================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au CCNA #CSCO12880208 ============================================================== -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sat, Aug 24, 2019 at 2:37 PM, Rodney Baker wrote:

On Saturday, 24 August 2019 18:16:46 ACST Oleksii Vilchanskyi wrote:

...

Obviously, nobody can remember to manually run a program to check for .rpmnew every upgrade. Can zypper notify about this at the end automatically? The only reference I found googling "zypper notify about rpmnew" was [0] with a broken link to openFATE. Was it ever implemented?

[0]: https://lists.opensuse.org/opensuse-features/2013-02/msg00022.html

[...]

This is one thing that apt (debian) does well - where there is a configuration file to be replaced or updated, it displays a prompt with the options to Overwrite with the developer's config, keep the original config, or display the changes/differences and choose between them. If apt can do it, why not zypper?

It is quite an issue with non-interactive mode in apt, although so is interactive problem solving in zypper. LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sat, Aug 24, Oleksii Vilchanskyi wrote:

Obviously, nobody can remember to manually run a program to check for .rpmnew every upgrade. Can zypper notify about this at the end automatically? The only reference I found googling "zypper notify about rpmnew" was [0] with a broken link to openFATE. Was it ever implemented?

Implementing this would be a waste of manpower, given that /etc should not be polluted anymore by packages. File a bug to get the affected package fixed to not pollute /etc (and hopefully also /usr/etc!). If there was indeed an incompatible change, something has to transform the old config to the new config in some way. I think there are ways to show notifications at the end of an upgrade, this feature is used every now and then. Olaf

On 24/08/2019 22:31, Olaf Hering wrote:

On Sat, Aug 24, Oleksii Vilchanskyi wrote:

...

Obviously, nobody can remember to manually run a program to check for .rpmnew every upgrade. Can zypper notify about this at the end automatically? The only reference I found googling "zypper notify about rpmnew" was [0] with a broken link to openFATE. Was it ever implemented?

Implementing this would be a waste of manpower, given that /etc should not be polluted anymore by packages. File a bug to get the affected package fixed to not pollute /etc (and hopefully also /usr/etc!).

If there was indeed an incompatible change, something has to transform the old config to the new config in some way. I think there are ways to show notifications at the end of an upgrade, this feature is used every now and then.

When I wrote this I meant something really simple and without separate /etc in mind, a-la system("rpmconf -t -o <list of upgraded packages>"); And then just inform the user, e.g.: "The following packages have RPM configuration files that require merging: package1 package2 To merge configuration files of one package, run `rpmconf -o <package-name>`. To merge all configuration files, run `rpmconf -a`." IIUC when there is an incompatible change, the new config is installed anyway, and the old one is saved in .rpmsave. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am Sun, 25 Aug 2019 10:48:52 +0200 schrieb Oleksii Vilchanskyi :

IIUC when there is an incompatible change, the new config is installed anyway, and the old one is saved in .rpmsave.

With an empty /etc, this can not possibly happen anymore in the future due to lack of .rpmnew/save in /etc. What should happen in some way is a notification to the admin about required changes to untracked configuration files. Today such .rpmnew is (most likely) the only hint. It is obviously a very bad UI for notification. And such notification has to happen anyway, whether rpm packages populate /etc or not. Olaf

Hello, Am Sonntag, 25. August 2019, 14:57:44 CEST schrieb Carlos E. R.:

On Saturday, 2019-08-24 at 22:31 +0200, Olaf Hering wrote:

...

On Sat, Aug 24, Oleksii Vilchanskyi wrote:

...

Obviously, nobody can remember to manually run a program to check for .rpmnew every upgrade. Can zypper notify about this at the end automatically? The only reference I found googling "zypper notify about rpmnew" was [0] with a broken link to openFATE. Was it ever implemented?> Implementing this would be a waste of manpower, given that /etc should not be polluted anymore by packages. File a bug to get the affected package fixed to not pollute /etc (and hopefully also /usr/etc!). And how will that help when the defaults change?

Ie, we have installed version 1.1.1, and have /usr/etc/someconfig. We get an update to 1.1.2, which overwrites /usr/etc/someconfig, which has a single line changed to another default, which happens to modify the behaviour of the tool significantly, without the admin getting

As a sidenote - if such a change reallly happens in a minor release, then please blame whoever did it. Minor releases shouldn't do such changes.

any hint that there was a modification applied, because now there are no .rpm* files to compare to.

Fine, fine improvement! :-(

Actually there isn't a real change - as long as you didn't modify a config file, rpm will silently replace it without leaving a *.rpmsave or *.rpmnew behind. You'll get these files only if the packaged file changed _and_ you modified the file _and_ it is marked as a config file.

...

If there was indeed an incompatible change, something has to transform the old config to the new config in some way. I think there are ways to show notifications at the end of an upgrade, this feature is used every now and then.

Zypper might compare (diff) the old and the new config and highlight the changes, or just say that there are changes.

That would be a feature request which probably needs quite some implementation time, and becomes less useful once we have the default config moved to /usr/etc/. I have to admit that I often dreamed of a "zypper diff" command to find out in which way a config file was modified (compared to the packaged config), but moving the defaults to /usr/etc/ and having only the local "overrides" in /etc/ makes even more sense IMHO, and avoids the mixup of packaged default config and admin-modified parts. Nevertheless, a (more or less) quick solution might be to add a hook in /usr/lib/zypp/plugins/commit that calls rpmconfigcheck and displays its output. (Unfortunately creating a symlink to rpmconfigcheck there doesn't work, so you'll need to look into the details of how zypper handles plugins to get this done.)

Sometimes there is a .rpm* identical to the active file, waste of time.

Yeah, I remember such cases, and agree that it shouldn't happen. At least diffing to the active file is easy in such cases ;-) Regards, Christian Boltz -- Direkter Mailkontakt mit dem Paketmacher. Tränen, Gewaltandrohnung, knappe Unterwäsche - als nix genützt. Abgelehnt. [Ratti ueber einen Aenderungswunsch an einem SuSE-Paket] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

hi, the old my.cnf.contained more lines socket     = /var/run/mysql/mysql.sock  ==> in my.cnf;rpmnew it is a comment without initial /var Next 3 lines are missing in my.cnf.rpmnew (maybe these are the culprit refers to an old version?) innodb_file_format=Barracuda innodb_file_per_table=ON version=10.2.24-MariaDB One more line found in my;cnf.rpmnew: "secure_file_priv = /var/lib/mysql-files" Regards Patrick Shanahan a écrit :

...

Hello,

After zypper dup mariadb cannot be started. Replacing old "/etc/cnf" by "/etc/my.cnf.rpmnew" solves the problem. Regards I ran akonadictl restart

* Philippe Conde [08-24-19 03:47]: then systemctl restart mysql and cleared the running processes using deleted files

didn't even suspect a new my.cnf, but looking now there is not one.

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 24/08/2019 14.00, Philippe Conde wrote:

hi,

the old my.cnf.contained more lines socket     = /var/run/mysql/mysql.sock  ==> in my.cnf;rpmnew it is a comment without initial /var

Next 3 lines are missing in my.cnf.rpmnew (maybe these are the culprit refers to an old version?) innodb_file_format=Barracuda innodb_file_per_table=ON version=10.2.24-MariaDB

One more line found in my;cnf.rpmnew: "secure_file_priv = /var/lib/mysql-files"

The thing is, you have to review, then validate or reject each one of those changes. And check the log to see why a service does not restart. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)