March 2021 - YaST Development - openSUSE Mailing Lists

Exploring desktop WYSIWYG on linux
by josef Reidinger 17 Mar '21

17 Mar '21

Hi, it is a bit of follow-up of ancor playing with tk and its ruby DSL. I write idea that I like for UI design to use WYSIWYG instead of programmer created UI from programming language. My previous experience was just with visual basic ( 20 years ago ) and netbeans one for swing ( 12 years ago )[1]. My quick search shows glade, qt designer and camelot. Glade is for gtk and as we do not support now gtk backend I do not explore it too much. Camelot on other hand looks quite focused on database representation so also not much for us. So I explore and play a bit with qt designer. At first I was quite surprised that I do not find qt designer and it looks like it is now only part of qt creator ( qt IDE ), at least I do not find own rpm or how to start it. So I create testing project and start. The output is ui file which is XML based, so quite easy to parse and hard to read for human. But looks quite promising for us to parse it and e.g. try to show ncurse equivalent. Widgets in XML has its id, so it should be easy to connect widgets with actions in programming language as for us the direct connect in designer does not make much sense and I do not like it much. I think that GUI layout should be in WYSIWYG, but connection to data model should be in code. I try layouts available and I am not sure if it is limitation of designer or qt, but all layouts are quite trivial and nothing like Spring Layout[2] in Netbeans which allows to specify constrains on widgets like align left side to center of this widget and have right side align with left of different widget. Situation with layouts was even worse for me and I failed to create design that works well with resizing of window ( maybe issue was that I use MainDialog as base? ). Probably issue on my side, but it says something about usability of designer. Nice feature is also builtin tooltips and translations, but I worry how easy will be to use gettext for translations instead of qt built-in localization. There are some widgets that are currently not supported by libyui. What I like in designer is clear separation of input and display widgets. So it is clear which ones are for displaying info and which should be used for getting data. I try to design more complex menu with submenus and it works nicely in designer. Overall qt designer for me is comparable to visual basic experience 20 years ago and still not so nice experience as netbeans designer 12 years ago. So if you know better WYSIWYG designer that I overlook, please write it. But still it is better then write own one, so maybe in future I will try to write trivial ui file displayer in libyui bindings or directly in yast with ycp-ui-bindings. Josef [1] https://netbeans.apache.org//kb/docs/java/quickstart-gui.html [2] https://docs.oracle.com/javase/tutorial/uiswing/layout/spring.html

6 11

Counting LOC in yast and libyui Github organizations
by David Díaz 17 Mar '21

17 Mar '21

Hi! Today the question "does anyone know how many LOC we maintain" arose in the #yast channel at the freenode.net IRC server. And although most of us know about `wc -l` (in fact, my teammate Stefan suggested running `wc -l **/*.{rb,cc,h}` in a full checkout), I quickly wondered if someone already built a tool to perform such task against all repos of a Github organization. And the answer is yes, Ben Balter[1] did it 5 years ago and called it count-org-loc[2] which under the hood uses cloc[3] (a tool written in Perl for counting blank, comment, and physical lines of code in many programming languages) in a similar way as it is explained in this[4] StackOverflow answer. Although I was aware that the results do not answer the original question, since not every repository at Github yast organization is maintained by the YaST team core, I ran it against both, yast and libyui Github organizations. You can see the results I got at [5] and [6]. Just if you are as curious as I am :P BTW, I installed cloc via npm[7] because the available 1-click install[8] for Tumbleweed didn't work for me. Hope you can forgive me :) :P [1] https://github.com/benbalter [2] https://github.com/benbalter/count-org-loc [3] https://github.com/AlDanial/cloc#Docker- [4] https://stackoverflow.com/a/29012789 [5] https://gist.github.com/dgdavid/086010eb369d895f121e76f0dc6154f4 [6] https://gist.github.com/dgdavid/90022844a5891a9aa893e961d1549b55 [7] https://github.com/kentcdodds/cloc#readme [8] https://software.opensuse.org/download/package?package=cloc&project=Documen… -- David Díaz YaST Team at SUSE LINUX GmbH IRC: dgdavid

4 6

Github labels in the YaST organization
by Ancor Gonzalez Sosa 16 Mar '21

16 Mar '21

As everyone in this list likely know, the two "official" channels used by the YaST Team at SUSE to track changes requested to YaST are: - https://bugzilla.suse.com (also available as https://bugzilla.opensuse.org) - https://jira.suse.com (also open for openSUSE feature requests) We have well-established mechanisms to process the constant flow of Bugzilla and Jira entries and to track them over time. But since we are getting more and more request via Github issues, we agreed to establish some procedure to try to ensure requests via Github don't get overlooked and forgotten. Today we decided we will create a few labels in all repositories under the YaST organization at Github (we got a script to do perform such batch creation in all repos) and we will use them to know if a given issue needs attention. So this mail is a RFC for the initial set of labels. Please feel free to propose any enhancement, specially to the names of the labels that I just made up. We kind of agreed to start with these four: 1) Label "feedback" To mark issues that are used to discuss future enhancements or relatively general topics. Examples: https://github.com/yast/yast-firstboot/issues/115, https://github.com/yast/yast-installation/issues/903 and all their associated (sub)issues. 2) Label "tracked" To mark bug reports or feature requests that are already processed by someone in the team and have a counterpart in the official Bugzilla, Jira or in the internal Trello board of the YaST Team. That would be the equivalent of moving a bugzilla bug from yast2-maintaners to yast-internal. 3) Label "other-maintainer" To mark issues associated to YaST repositories and/or functionalities that are not maintained by the core YaST Team. Examples: https://github.com/yast/yast-auth-server/issues or https://github.com/yast/yast-crowbar/issues/68 4) Label "needinfo" Similar to the corresponding flag in bugzilla. The main difference is that the YaST Team will need to take full care of the label (eg. removing it if the info was already provided) since not everyone will have the rights to add/remove labels. As said, feel free to propose any change (including names). We plan to mass-create the tags tomorrow. Cheers. -- Ancor González Sosa YaST Team at SUSE Software Solutions

2 1

CI (GitHub Actions/Travis) broken due to Glibc upgrade :-(
by Ladislav Slezak 15 Mar '21

15 Mar '21

Hi, TLDR: Travis/Github Actions are broken right now, ignore the failures :-/ The Tumbleweed distro upgraded Glibc to version 2.33. This uses a new syscall (faccessat2) which requires a newer kernel (5.8+) and some support in Docker. Unfortunately these are not present in the Ubuntu workers running at GitHub or Travis so the result is many EPERM exceptions or not found file errors. The bad part is that we cannot do much about it :-( Either TW disables that syscall or Github/Travis upgrades the workers to support that. The only workaround would be to use the Leap 15.3 as the base distro for CI. So far there should not big differences so that should work fine, at least for some time. We could use it until the issue is resolved, later we can switch back to TW. BTW the same problem also happens in other distros and in other systems (even WSL has been reported). This clearly shows the disadvantage of containers. Even if we bundle our complete openSUSE user space stack (down to glibc) we still rely on the host kernel (Ubuntu in this case) and this might cause some incompatibilities... :-/ Some links: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/… https://github.com/microsoft/WSL/issues/6562 https://docs.docker.com/engine/release-notes/#security-1 -- Ladislav Slezák YaST Developer SUSE LINUX, s.r.o. Corso IIa Křižíkova 148/34 18600 Praha 8

2 3

Pending Pull Requests
by yast-ci＠opensuse.org 15 Mar '21

15 Mar '21

This email is automatic generated from yast CI node. It lists of pull requests that have no activity more then three working days. If your module is listed, please check all pull request, why they are not merged yet. Pending requests in repository yast-installation: - Master base product logging (30 days) https://github.com/yast/yast-installation/pull/907 - Replace old splash commands with plymouth ones (54 days) https://github.com/yast/yast-installation/pull/904 Pending requests in repository yast-instserver: - Adapt Rakefile and Dockerfile for SLE-15-SP2 (121 days) https://github.com/yast/yast-instserver/pull/50 Pending requests in repository yast-metapackage-handler: - Add unit tests for methods of OneClickInstallWorkerFunctions class (41 days) https://github.com/yast/yast-metapackage-handler/pull/25 - Extend unit test for existing functions (62 days) https://github.com/yast/yast-metapackage-handler/pull/23 Pending requests in repository yast-online-update: - Added recommends to yast2-online-update-frontend (bsc#1177997) (130 days) https://github.com/yast/yast-online-update/pull/33 Pending requests in repository yast-packager: - Adding NFS repository: Checking user input e.g. white spaces in serve… (95 days) https://github.com/yast/yast-packager/pull/543 - Include some hints in the "Priority" label (bsc#1154693) (163 days) https://github.com/yast/yast-packager/pull/482 Pending requests in repository yast-python-bindings: - Fix backtrace formatting in YPython::PyErrorHandler() (20 days) https://github.com/yast/yast-python-bindings/pull/36 Pending requests in repository yast-registration: - Master base product logging (30 days) https://github.com/yast/yast-registration/pull/529 Pending requests in repository yast-theme: - Add pattern-budgie icon (boo#1176164) (24 days) https://github.com/yast/yast-theme/pull/131 Pending requests in repository yast-yast2: - Logging all available products information into directory /var/log/Y… (30 days) https://github.com/yast/yast-yast2/pull/1135 Pending requests in repository yast-ycp-ui-bindings: - Failing autowrap (96 days) https://github.com/yast/yast-ycp-ui-bindings/pull/64 - New UI Example for ComboBox (111 days) https://github.com/yast/yast-ycp-ui-bindings/pull/62 Pending requests in repository yast-ruby-bindings: - Logging all available products information into directory /var/log/Ya… (30 days) https://github.com/yast/yast-ruby-bindings/pull/267 Pending requests in repository skelcd-control-openSUSE: - Ntp servers (62 days) https://github.com/yast/skelcd-control-openSUSE/pull/223 Pending requests in repository yast-auth-client: - Bsc1172340 (108 days) https://github.com/yast/yast-auth-client/pull/94 Pending requests in repository yast-auth-server: - Bsc1172340 (108 days) https://github.com/yast/yast-auth-server/pull/66 - Fix an issue where pkg dependencies were not install (170 days) https://github.com/yast/yast-auth-server/pull/63 - Fixes to make the YaST modules work (627 days) https://github.com/yast/yast-auth-server/pull/48 Pending requests in repository yast-journal: - Use Yast::Builtins.strftime in 'Change Filter' dialog (160 days) https://github.com/yast/yast-journal/pull/45 Pending requests in repository yast-storage-ng: - Partial fix for bug#176140 (117 days) https://github.com/yast/yast-storage-ng/pull/1166 - Display pathnames correctly in a Right-to-Left context (bsc#1128091) (111 days) https://github.com/yast/yast-storage-ng/pull/873 Pending requests in repository docker-yast-ruby: - drop travis (48 days) https://github.com/yast/docker-yast-ruby/pull/37 Pending requests in repository docker-yast-cpp: - drop travis (48 days) https://github.com/yast/docker-yast-cpp/pull/26 Pending requests in repository skelcd-control-leanos: - Default ntp servers (62 days) https://github.com/yast/skelcd-control-leanos/pull/72 Pending requests in repository yast-rmt: - Add metadata into packages (161 days) https://github.com/yast/yast-rmt/pull/51 - use docker image from OBS (180 days) https://github.com/yast/yast-rmt/pull/50 - Enforce full coverage (180 days) https://github.com/yast/yast-rmt/pull/40 Pending requests in repository skelcd-control-MicroOS: - sync with SLE (102 days) https://github.com/yast/skelcd-control-MicroOS/pull/27 - unify proposed partition sizes with openSUSE MicroOS (103 days) https://github.com/yast/skelcd-control-MicroOS/pull/26 Pending requests in repository skelcd-control-SMO: - install the microos-selinux pattern by default (34 days) https://github.com/yast/skelcd-control-SMO/pull/6

1 0

Exploring Ruby DSLs for UI building... and Tk!
by Ancor Gonzalez Sosa 12 Mar '21

12 Mar '21

Disclaimer: I'm definitely not advocating to use Tk instead of libYUI or Qt. I'm perfectly aware that Tk is not exactly "the future" (unless you are somehow reading this from 1996). Having said that... Not so long ago, we were discussing about the future of libYUI, about how we use it currently in YaST (with those intermediate YCP bindings that provide some kind of DSL with the cost of loosing direct access to the original OOP API of libYUI) and about how we would like to write the UI code from Ruby in the future. At some other recent point in time, we were also toying with the idea of having the possibility to define grid-based layouts for libYUI interfaces, although that project never took off. Fast-forward to yesterday's morning. I wanted to use part of my research time to take a look to other ruby-based UI DSLs out there and I did it by developing this: https://github.com/ancorgs/glimmer-tk-calculator Let me explain what it is and what can we learn from it (if anything). 1) What is Glimmer? Not being technically precise, we could say Glimmer is a GUI development library for Ruby (JRuby and Opal). You specify your UI in a pretty nice DSL and you get a SWT interface if you are using JRuby. https://github.com/AndyObtiva/glimmer-dsl-swt That same code can be executed in a web browser using OPAL and that UI will be rendered in HTML+Javascript. https://github.com/AndyObtiva/glimmer-dsl-opal One of the cool features of Glimmer is that it offers a data-binding library that works very well out of the box to connect elements on the interface with elements on the underlying model. In my experience, bidirectional data-binding is a tool that must be used with care but that is really useful in many situations. 2) What is Glimmer-DSL-Tk So far just an experiment form the original Glimmer developer to bring the functionality of Glimmer to MRI Ruby. The DSL is not fully compatible with the one used by Glimmer to define interfaces in SWT and Opal. Instead, it's closer to the Tk API... which I found quite nice because it gave the opportunity to learn the Tk basis from a very convenient environment. As you can see here, you can write the UI in a thin object-oriented wrapper on top of Tk or using the nice Glimmer declarative syntax. https://github.com/AndyObtiva/glimmer-dsl-tk#glimmer-gui-dsl-concepts 3) My experiment I just stole a calculator model from one of the Glimmer SWT/Opal demos and wrote an UI for it using glimmer-dsl-tk. As you can see, the UI code is really declarative and free of manual steps like populating values or taking care of the event loop. There is also no boilerplate code like the one we have in YaST to connect our object-oriented CWM widgets to the underlying model (you know, defining #init, #store, etc.). https://github.com/ancorgs/glimmer-tk-calculator/blob/master/lib/views/glim… Data-binding works like a charm. This simple call you can find in the code does all the connection magic, providing interactivity for free: bind(presenter, :result) It was also an opportunity to me to learn about Tk's grid layout system. It's pretty neat. It's based in just a few simple concepts and it's quite easy to understand, but it still gives the developer quite some power. It's true that, used directly, it pollutes a bit the UI code (as you can see in my code). But it should be easy to find a way to not need to pass all those row/column values to every single widget. I though the whole Tk approach would work quite well for a TUI as well... and I was not the first one. There are two implementations of Tk for ncurses. The development of both was stopped a looong time ago and I would be surprised if any of them is still useful in modern times, but at least it looks like there is people who still try to keep them compiling with relatively recent versions of Tk. https://github.com/credil/ck https://github.com/rkeene/CTk As final words, I'm not saying we should adopt Tk and/or Glimmer, but I think we can take inspiration from both to whatever we do in the future regarding the UI. There are quite some neat ideas in both. Writing an interactive UI turned to be a quite pleasant experience with such tools (as opposed to our not-so-nice experience in YaST). Cheers. -- Ancor González Sosa YaST Team at SUSE Software Solutions

2 1

Pending Pull Requests
by yast-ci＠opensuse.org 08 Mar '21

08 Mar '21

This email is automatic generated from yast CI node. It lists of pull requests that have no activity more then three working days. If your module is listed, please check all pull request, why they are not merged yet. Pending requests in repository yast-installation: - Master base product logging (23 days) https://github.com/yast/yast-installation/pull/907 - Replace old splash commands with plymouth ones (47 days) https://github.com/yast/yast-installation/pull/904 Pending requests in repository yast-instserver: - Adapt Rakefile and Dockerfile for SLE-15-SP2 (114 days) https://github.com/yast/yast-instserver/pull/50 Pending requests in repository yast-metapackage-handler: - Add unit tests for methods of OneClickInstallWorkerFunctions class (34 days) https://github.com/yast/yast-metapackage-handler/pull/25 - Extend unit test for existing functions (55 days) https://github.com/yast/yast-metapackage-handler/pull/23 Pending requests in repository yast-network: - wpa_supplicant proposal switched to network-ng (27 days) https://github.com/yast/yast-network/pull/1154 Pending requests in repository yast-online-update: - Added recommends to yast2-online-update-frontend (bsc#1177997) (123 days) https://github.com/yast/yast-online-update/pull/33 Pending requests in repository yast-packager: - Adding NFS repository: Checking user input e.g. white spaces in serve… (88 days) https://github.com/yast/yast-packager/pull/543 - Include some hints in the "Priority" label (bsc#1154693) (156 days) https://github.com/yast/yast-packager/pull/482 Pending requests in repository yast-python-bindings: - Fix backtrace formatting in YPython::PyErrorHandler() (13 days) https://github.com/yast/yast-python-bindings/pull/36 Pending requests in repository yast-registration: - Master base product logging (23 days) https://github.com/yast/yast-registration/pull/529 Pending requests in repository yast-theme: - Add pattern-budgie icon (boo#1176164) (17 days) https://github.com/yast/yast-theme/pull/131 Pending requests in repository yast-yast2: - Logging all available products information into directory /var/log/Y… (23 days) https://github.com/yast/yast-yast2/pull/1135 Pending requests in repository yast-ycp-ui-bindings: - Failing autowrap (89 days) https://github.com/yast/yast-ycp-ui-bindings/pull/64 - New UI Example for ComboBox (104 days) https://github.com/yast/yast-ycp-ui-bindings/pull/62 Pending requests in repository yast-ruby-bindings: - Logging all available products information into directory /var/log/Ya… (23 days) https://github.com/yast/yast-ruby-bindings/pull/267 Pending requests in repository skelcd-control-openSUSE: - Ntp servers (55 days) https://github.com/yast/skelcd-control-openSUSE/pull/223 Pending requests in repository yast-auth-client: - Bsc1172340 (101 days) https://github.com/yast/yast-auth-client/pull/94 Pending requests in repository yast-auth-server: - Bsc1172340 (101 days) https://github.com/yast/yast-auth-server/pull/66 - Fix an issue where pkg dependencies were not install (163 days) https://github.com/yast/yast-auth-server/pull/63 - Fixes to make the YaST modules work (620 days) https://github.com/yast/yast-auth-server/pull/48 Pending requests in repository yast-journal: - Use Yast::Builtins.strftime in 'Change Filter' dialog (153 days) https://github.com/yast/yast-journal/pull/45 Pending requests in repository yast-storage-ng: - Partial fix for bug#176140 (110 days) https://github.com/yast/yast-storage-ng/pull/1166 - Display pathnames correctly in a Right-to-Left context (bsc#1128091) (104 days) https://github.com/yast/yast-storage-ng/pull/873 Pending requests in repository docker-yast-ruby: - drop travis (41 days) https://github.com/yast/docker-yast-ruby/pull/37 Pending requests in repository docker-yast-cpp: - drop travis (41 days) https://github.com/yast/docker-yast-cpp/pull/26 Pending requests in repository skelcd-control-leanos: - Default ntp servers (55 days) https://github.com/yast/skelcd-control-leanos/pull/72 Pending requests in repository yast-rmt: - Add metadata into packages (154 days) https://github.com/yast/yast-rmt/pull/51 - use docker image from OBS (173 days) https://github.com/yast/yast-rmt/pull/50 - Enforce full coverage (173 days) https://github.com/yast/yast-rmt/pull/40 Pending requests in repository skelcd-control-MicroOS: - sync with SLE (95 days) https://github.com/yast/skelcd-control-MicroOS/pull/27 - unify proposed partition sizes with openSUSE MicroOS (96 days) https://github.com/yast/skelcd-control-MicroOS/pull/26 Pending requests in repository skelcd-control-SMO: - install the microos-selinux pattern by default (27 days) https://github.com/yast/skelcd-control-SMO/pull/6

1 0

Beware: libzypp code cleanup - YAST related legacy code
by Michael Andres 05 Mar '21

05 Mar '21

Hi, we found some YAST(?) related legacy code inside libzypp, which we will remove in the next version unless someone speaks up now: 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. 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. Thanks. -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres, E&I, ma(a)suse.com, Phone: ++49 (0)911 - 74 053-0 +------------------------------------------------------------------+ SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg Germany, (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer +------------------------------------------------------------------+

3 2

Deprecating libyui repositories
by José Iván López González 05 Mar '21

05 Mar '21

Hi folks, In the YaST team, we are going to deprecate the current libyui repositories in favor of a new single libyui repo. That new libyui repository will contain all the code from the deprecated ones. There are several reasons to do it. In summary, we want to avoid some headaches when adding new features because we need to maintain source code (API) and binary (ABI) compatibility. You can find more about the motivation in [1,2]. Recently we also adapted the libyui repositories to use a new CMake build system [3,4,5]. And now this is the next step in order to make all the bulding/packaging system easier. The affected repositories are: https://github.com/libyui/libyui https://github.com/libyui/libyui-qt https://github.com/libyui/libyui-ncurses https://github.com/libyui/libyui-bindings https://github.com/libyui/libyui-qt-graph https://github.com/libyui/libyui-qt-pkg https://github.com/libyui/libyui-ncurses-pkg https://github.com/libyui/libyui-rest-api https://github.com/libyui/libyui-qt-rest-api https://github.com/libyui/libyui-ncurses-rest-api We are going to rename the master branch of these repositories as master_old. The new master branch will only contain a README.txt file in order to inform about the change, similar to [6]. Moreover, we will move the current libyui repository to something like libyui-old, because we will continue using the libyui repo name for the new repository. Note that the community maintained packages like libyui-gtk will not be adapted. These packages continue using their own builing/packaging system. If you have any question or you need to do some changes in any of the affected repos, please, contact YaST team. Thanks in advance. Regards, Iván [1] https://github.com/libyui/libyui/issues/177 [2] https://gist.github.com/shundhammer/b775dd4f8acd126be2166373e208e9bb [3] https://gist.github.com/shundhammer/2d2b9bcf4b62df5b139daeceec8283ab [4] https://gist.github.com/shundhammer/d96a63a1cab8245d20c2e3556238a114 [5] https://github.com/libyui/libyui/pull/178 [6] https://github.com/yast/yast-storage -- José Iván López González YaST Team at SUSE LINUX GmbH IRC: jilopez

1 0

Fw: Beware: libzypp code cleanup - YAST related legacy code
by josef Reidinger 05 Mar '21

05 Mar '21

Sending to mailing list to get answer. Josef Begin forwarded message: Date: Thu, 04 Mar 2021 16:25:42 -0700 From: "David Benjamin" <dbenjamin(a)ontario.k12.or.us> To: <jreidinger(a)suse.cz> 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 <jreidinger(a)suse.cz> 03/04/21 1:57 PM >>> On Thu, 4 Mar 2021 18:36:02 +0100 Michael Andres <ma(a)suse.com> 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-autoy… 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

1 0