Sending to mailing list to get answer. Josef Begin forwarded message: Date: Thu, 04 Mar 2021 16:25:42 -0700 From: "David Benjamin" To: Subject: Re: Beware: libzypp code cleanup - YAST related legacy code

Whoever compiled a linux kernel on a pre-Pentium architecture known, why this feature was valuable at that time.

What about Raspberry Pi? I don't do kernel compiles on mine, but maybe one day I will. Would this change impact Raspberry Pi adoption? David.

...

...

josef Reidinger 03/04/21 1:57 PM >>> On Thu, 4 Mar 2021 18:36:02 +0100 Michael Andres wrote:

Hi,

we found some YAST(?) related legacy code inside libzypp, which we will remove in the next version unless someone speaks up now:

Hi Michael, at first let me thank you for noticing us in advance.

Introduced before 2005 during commit:

A) Creation of /var/log/YaST2/config_diff_DATE.log files including the first 25 lines of config file diffs upon .rpmnew/.rpmsave creation.

B) After a write to the config_diff_DATE.log file, /var/lib/update-messages/yast2-packagemanager.rpmdb.configfiles is opened and immediately closed again.

I do not find any note about this files in our code. So looks like safe. Lada feel free to correct me.

We plan to drop that code. If you need something like this, we can provide you a callback sending the path of the 2 config files and you and create the diff as you need it..

C) zypp::RpmDb::setBackupPath called from within yast-pkg-bindings, src/Package.cc and available in ruby as Pkg.SetBackupPath().

This turns on creation of tarballs collecting the modified (binary) files of each package before updating it. This simple kind of backup was introduced to save self-compiled binaries/kernels before they were overwritten by rpm.

Whoever compiled a linux kernel on a pre-Pentium architecture known, why this feature was valuable at that time.

We will for now deprecate the method and disable the backup. However it may be that YAST still has has some 'Create backups during installation' button which triggers a call to this, please remove it. It's wasted time and disk space most probably.

I worry, that this part is not so simple. The call is used on two places and is driven by various inputs that decide if do backup or not. And one of that input (and not only one) is autoyast profile for autoupgrade. It is documented in SLE and opensuse documentation at https://doc.opensuse.org/documentation/leap/autoyast/single-html/book-autoya... backup->modified key. So I worry f it should be dropped we need to have: 1. jira entry which we can reference in changelog 2. release notes entry 3. docu task to adapt documentation 4. dev task to clean also yast code as it is used in various places. And as we do not yet separate SP3 and TW code, I worry we should not adapt code now to not break it and cause regression in SP3.

Thanks.

Thanks Josef