July 2013 - openSUSE Features - openSUSE Mailing Lists

[openFATE 305336] Ship man page for every executable
by fate_noreply＠suse.de 31 Jul '13

31 Jul '13

Feature changed by: Matthias Eckermann (mge1512) Feature #305336, revision 70 Title: Ship man page for every executable openSUSE-11.2: Rejected by Andreas Jaeger (a_jaeger) reject date: 2009-08-11 15:41:47 reject reason: This is a task that should be done in cooperation with the upstream projects. Priority Requester: Mandatory - openSUSE-11.4: Rejected by Matthias Eckermann (mge1512) - reject date: 2011-03-26 09:25:38 - reject reason: closing here, opening new + openSUSE-11.4: Rejected Priority Requester: Important Requested by: Matthias Eckermann (mge1512) Partner organization: openSUSE.org Description: 1. Even graphical applications need docs outside the application itself. The need to run the application, to know what does it does, is not good. 2. You need a standard documentation format; where standard = expected for people needing that documentation. Who are, often, not knowing the distro well (so the format can't be distro-specific). And the format must be the same for all binaries/packages. One can't rely on the fact it will always be easy and intuitive to find that some application is part KDE (for example) and one can get the documentation in konqueror when typing 'help:/application'. 3. To view the documentation must be as easy as possible and with as minimal resources as possible. This is why online documentation is not so good (you need a running Internet net connection), documentation in a web browser as well (you need X and graphical desktop). HTML is questionable as it (as a format) allows so many extensions that it is needed to expect that such documentation will not be readable in text browsers after some time. 4. Many parts are shared between openSUSE and the enterprise products. And, in the enterprise world, we need to be much more standard conforming. Including the documentation. A UNIX admin will use the 'man' command for getting info about the binary. 'info' system is here as well, for many years. But 'man' is still more usual. Imagine a server room with hundreds/thousands of servers of several UN*X clones - 'man' works everywhere, and Linux is expected to be "on par" also with respect to those capabilities. These four points stay behind the idea of man pages needed and provided for everything. Relations: - How to Create Manpages with DocBook (url: http://en.opensuse.org/Manual_Pages/How_to_Create_Manpages_with_DocBook) - At http://en.opensuse.org/Manual_Pages/Missing a list of all packages with missing man pages can be found (url: http://en.opensuse.org/Manual_Pages/Missing) Use Case: User / Administrator should find a dedicated man page for every executable in openSUSE and SUSE Linux Enterprise systems. Discussion: #2: Stefan Behlert (sbehlert) (2008-10-22 15:00:11) I agree with the intention, but shouldn't it be rather 'documentation for each executable'? Newer stuff uses mostly info-pages, afaiks #3: Matthias Eckermann (mge1512) (2008-11-10 14:31:15) (reply to #2) It is valid to have a pointer to the info pages in the man-pages, sure. But man-pages are the UNIX proposed way of doing documentation. #47: Christopher Yeleighton (yecril71pl) (2012-09-22 15:12:11) (reply to #3) openSUSE is based on GNU. GNU is not UNIX, so I fail to see how this is relevant. #9: Thomas Schraitle (thomas-schraitle) (2009-02-20 09:54:09) IMHO DocBook would be very suitable for this task as nobody has to learn the awkward syntax of groff/troff/... For example, I've submitted a DocBook file to the scout author and he generates the manpage with the DocBook stylesheets automatically. If you think, a manpage is not enough, each DocBook file can be easily transformed into (X)HTML, PDF, or almost any other output formats. IHMO it saves time if you want to support more formats than just manpage. The whole process is documented here: http://en.opensuse.org/Manual_Pages/How_to_Create_Manpages_with_DocBook #10: Jan Engelhardt (jengelh) (2009-02-21 20:31:14) (reply to #9) Manpages are very suitable for this task as nobody has to learn the awkward DocBook syntax. If done right, manpages are just another markup language and there are just a few elements one needs to know. (You can even count them in your hands: .TH, .SH, .SS, .PP, .TP, .nf/.fi, \fB, \fI, \fP, and sometimes . IP. They almost map to HTML's title, h1, h2, p, (no direct eqv), pre, b, i, /b|/i, and ol|ul, respectively.) #11: Praveen Kunjapur (stilo_vingyou) (2009-04-09 21:38:39) Knowledge is power. #13: Thorsten Kukuk (kukuk) (2009-08-17 22:17:33) We have a huge amount of orphaned packages, there is no chance to do any additional work on this feature. #21: Juergen Weigert (jnweiger) (2009-09-07 17:36:35) No. I cannot even estimate what the docimpact might be. Someone please collect a list of executables, and describe what kind of work is expected on them. Then we can make estimates. From the above comments #13 to #18 I cannot extract useful information. #22: Thorsten Kukuk (kukuk) (2009-09-10 09:53:11) It is still not clear to me what PM is expecting. For adding all the manual pages to every single RPM we don't have the resources, meanwhile the strategy and resource situation changed dramatically. And touching all RPMs would mean, that an online update is nearly impossible, customers have to download nearly every installed RPM. Else I can only repeat my comment #15 #34: Thomas Schraitle (thomas-schraitle) (2009-09-10 14:29:21) I don't think some issues in this entry are really covered yet -- apart from any future decision: 1) Writing manpages for all executables is illusionary. This task has to be and can only be handled by the corresponding upstream projects. Maybe you can convince the project maintainers to improve their documentation in this regard or support them with trainees or the like. But it's a longterm goal, not something done between two months. 2) Firefox is an executable. Does it need a manpage? I would say no, it has other documentation. What qualifies an executable to get a manpage? Where do you draw the line? 3) Writing a manpage is one thing, maintaining it is another. As experience shows, sometimes you have significant changes between one version and the other. Which should be covered in the manpage, of course. Again, this can not be done inhouse, it is a task which can only be written by the upstream projects accordingly. 4) As already written in comment #21, no list is/was collected. 5) As outlined, IHMO documentation departement is the wrong addressee. #35: Matthias Eckermann (mge1512) (2009-09-10 14:53:27) (reply to #34) >I don't think some issues in this entry are really covered yet -- apart from any future decision: Be sure that this has been discussed already in depth, e.g. by the PM Team within SUSE/Novell. > Writing manpages for all executables is illusionary. This task has to be and > can only be handled by the corresponding upstream projects. Man pages do exist for most binaries in the open source community, many also independendly of the respective projects. The Debian community has done a great job here, and it could be useful to join the forces of openSUSE community with Debian here. ... > Maybe you can convince the project maintainers to improve their documentation in > this regard or support them with trainees or the like. But it's a longterm goal, > not something done between two months. That's why the feature already exists for one year, ... > Firefox is an executable. Does it need a manpage? I would say no, > it has other documentation. What qualifies an executable to get > a manpage? Where do you draw the line? In the Enterprise world every binary needs a man page. Including Firefox and all Gnome and KDE applications. One reason for that: no administrator wants to have binaries around, where (s)he cannot say, what it is used for. This might also be a matter of "compliance". I agree however that this is different for openSUSE and the community. > Writing a manpage is one thing, maintaining it is another. > As experience shows, sometimes you have significant changes between > one version and the other. Which should be covered in the manpage, of course. > Again, this can not be done inhouse, it is a task which can only be written > by the upstream projects accordingly. Agreed. > As already written in comment #21, no list is/was collected. This is wrong. In the package "man-pages-supplement" a script exists, to list all binaries without a man-page already. Thus the analysis itself is not difficult. The doing is the challenge. Indeed. #37: Pavol Rusnak (prusnak) (2009-09-10 14:54:24) (reply to #34) 2. EVERY executable, the title of the feature says it all. Even if the manpage only contains "Firefox is a web browser" it is better than nothing. 4. Wrong, list is attached as external reference - http://en.opensuse.org/Manual_Pages/Missing (I collected it in February 2009, so it is a little bit outdated). 5. I don't think this could be done in one departement, because this is huge amount of work. We could start adopting already written manpages from Debian, but still a longterm issue. #38: Thomas Schraitle (thomas-schraitle) (2009-09-10 15:32:43) (reply to #37) > 4. Wrong, list is attached as external reference - http://en.opensuse.org/Manual_Pages/Missing (I collected it in February 2009, so it is a little bit outdated). Thanks Pavol, for the reminder. The list is one part and we know what's missing. That's good. However, what we don't know is the effort/amount of work to make it. It can be a very short one, or something that is really complicated and you need special knowledge. Maybe some could be autogenerated. -- openSUSE Feature: https://features.opensuse.org/305336

1 0

[New: openFATE 316132] Add guest virtualization migration tools (virt-v2v) to distribution
by fate_noreply＠suse.de 30 Jul '13

30 Jul '13

Feature added by: Raine Curtis (grep4linux) Feature #316132, revision 1 Title: Add guest virtualization migration tools (virt-v2v) to distribution openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Raine Curtis (grep4linux) Partner organization: openSUSE.org Description: The open source virt-v2v project provides customers the ablity to convert guests from a foreign hypervisor to run on KVM, managed by libvirt. It needs to migrate SUSE Linux and Windows guests running on Xen, VirtualBox, and VMware ESX to KVM. It will enable VirtIO drivers in the converted guest if possible. Additional Packages required for virt-v2v : perl-Term-ProgressBar-2.10 perl-XML-DOM-XPath-0.14-3.20 libguestfs0-1.20.9-4.20 guestfs-tools-1.20.9-4.20 perl-Sys-Guestfs-1.20.9-4.20 libhivex0-1.3.7-2.10 hivex-1.3.7-2.10 perl-Win-Hivex-1.3.7-2.10 grubby-8.25-2.1 Use Case: A v2v tool will allow for customers to migrate from XEN and ESX to KVM running on SUSE Linux. -- openSUSE Feature: https://features.opensuse.org/316132

1 5

[New: openFATE 309148] boot-process: starting network / dbus with ldap authentification
by fate_noreply＠suse.de 30 Jul '13

30 Jul '13

Feature added by: Alexander Fleischer (afleischer) Feature #309148, revision 1 Title: boot-process: starting network / dbus with ldap authentification openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Alexander Fleischer (afleischer) Description: I asked to file this bug report as feature request: https://bugzilla.novell.com/show_bug.cgi?id=569953 (https://bugzilla.novell.com/show_bug.cgi?id=569953) After configuring LDAP authentification via yast the system needs about 20 minutes to start the dbus-daemon on boot. I got a lot of ldap messages in /var/log/messages like these: Jan 12 12:01:44 w2 dbus-daemon: nss_ldap: failed to bind to LDAP server ldaps://10.0.0.10: Can't contact LDAP server Jan 12 12:01:44 w2 dbus-daemon: nss_ldap: reconnecting to LDAP server (sleeping 8 seconds)... Of course, because network is started after dbus, dbus can't connect to the ldap server, and waits several times until the timeout is reached. Network has dbus as "required-start", so i can't change the startup order and add $network to required-start in the dbus script. My temporary solution is to replace the /etc/nsswitch.conf file with a one without ldap access in /etc/init.d/boot.local and restoring the original one after the network is up. But this is not a clean solution, maybe an extra startup script can solve the problem. -- openSUSE Feature: https://features.opensuse.org/309148

1 2

[openFATE 313143] YaST LDAP client refactor/cleanup
by fate_noreply＠suse.de 30 Jul '13

30 Jul '13

Feature changed by: Lukas Ocilka (locilka) Feature #313143, revision 13 Title: YaST LDAP client refactor/cleanup openSUSE Distribution: Unconfirmed Priority Requester: Mandatory Requested by: Ralf Haferkamp (rhafer) Partner organization: openSUSE.org Description: Jiri (jsuchome) an I recently discussed some cleanup work we'd like to see in the YaST ldap-client module. This feature lists the main items we'd like to see reworked to improve the Module: Remove no longer needed UI elements Candidates are: * The TLS/SSL checkbox (sssd has a hard requirement for SSL/TLS) * The "LDAP Version 2" checkbox in the advanced settings. (there is AFAIK no LDAPv2-only Server implementation left) * The "Use LDAP but Disable Login" Radio Button Restrict the UI to handle only really LDAP client related things Currently the UI contains quite some settings which are not strictly related to LDAP client (nss/pam) setup. Over the year ldap-client became a bit of a disposal site for all kinds of LDAP related things, which made the UI a bit hard to understand. We should move some things to YaST modules where make a better fit. This is mostly about the settings currently available in the "Administration Settings" Tab (in "Advanced Configuration") * The Password Policies settings seem to fit better into the ldap- server module which already contains some of this functionality * Default Configuration Objects for other YaST modules (e.g. mail, dns, dhcp). Where possible the need for those special configuration objects should be removed. When a specific service still requires those configuration objects the YaST module for that service should be able to handle those objects it self (we could still offer utils API for that in yast2-ldap/ldap-client). E.g. the user management related object should be configured from inside the yast2-users module. yast2- ldap-server could offer to create default objects during the initial LDAP server setup. * The Home Directories on This Machine checkbox seems to be better suite in the Users module as well. * The rest of the values which go to /etc/sysconfig/ldap could be written by yast2-ldap-servers. We still need to figure out how to setup /etc/sysconfig/ldap on machines which to not run the LDAP Server but need access to those settings. (yast2-mail, -dns-server, -dhcp-server) * Adapt the API: move the LDAP* functions from ldap-client (impact on other modules!) Relations: - related feature (feature/id: 313142) Discussion: #1: Jiří Suchomel (jsuchome) (2012-01-19 10:15:11) 1. Removing TLS/SSL is based on assumption that we configure SSSD only, which is feature 313142. 2. About The "Use LDAP but Disable Login" Radio Button: did we agree on some replacement of it? I cannot remember... #2: Jiří Suchomel (jsuchome) (2012-01-23 16:25:33) Added attachment proposal for simplified first screen (ldap-client- redesign2.png) #3: Jiří Suchomel (jsuchome) (2012-02-21 09:26:08) yast2-ldap-client-2.22.3 only offers SSSD configuration in UI, and the option to turn off TLS/SSL was removed. #5: Jiří Suchomel (jsuchome) (2012-02-21 11:37:45) (reply to #3) yast2-ldap-client-2.22.4 has the password policy configuration removed. Some parts were moved to yast2-ldap-server code (just svn), some other parts need to be added there. I've created a bug report to track it, see bnc#748004. #4: Jiří Suchomel (jsuchome) (2012-02-21 10:26:39) Default Configuration Objects for other YaST modules (e.g. mail, dns, dhcp). Where possible the need for those special configuration objects should be removed. Ralf, do you have any idea where it could/should be removed? Who can decide it? #6: Jiří Suchomel (jsuchome) (2012-04-19 08:52:07) OK, I've made most of the required changes in yast2-ldap-client, yast2- users and yast2-ldap-server. Ralf, could you take a look at current (Factory) versions of these and comment what else should be done? I mean mostly UI-wise, that API transition was not done. + #7: Lukas Ocilka (locilka) (2013-07-30 14:38:43) (reply to #6) + Ralf: ping -- openSUSE Feature: https://features.opensuse.org/313143

1 0

[openFATE 312568] YaST: add support for systemd service in runlevel editor
by fate_noreply＠suse.de 30 Jul '13

30 Jul '13

Feature changed by: Lukas Ocilka (locilka) Feature #312568, revision 10 Title: YaST: add support for systemd service in runlevel editor openSUSE Distribution: Evaluation by project manager Priority Requester: Important Requested by: Frederic Crozat (fcrozat) Partner organization: openSUSE.org Description: Yast runlevel editor should be able to detect if systemd is running and allow to enable/disable systemd service (which can shadow some sysvinit services). Relations: - systemd adaptation of YaST (novell/bugzilla/id: https://bugzilla.novell.com/show_bug.cgi?id=664548) https://bugzilla.novell.com/show_bug.cgi?id=https://bugzilla.novell.com/sho… Discussion: #2: Frederic Crozat (fcrozat) (2012-01-06 11:27:40) YaST support (probably adding a service) should talk to systemd using D- Bus API (like it is already done in systemd gtk gui), so it won't have to handle merge of configuration and so on. #3: Andreas Jaeger (a_jaeger) (2013-07-19 11:14:53) Isn't this done already? #4: Frederic Crozat (fcrozat) (2013-07-19 11:33:27) (reply to #3) it is : http://kobliha-suse.blogspot.fr/2013/06/yast-runlevel-is-dead-long-live-yas… #5: Andreas Jaeger (a_jaeger) (2013-07-19 11:35:51) (reply to #4) Thanks - written in ruby. So, if we go to ruby, this is done. Thus not marking yet as done but leaving it open for evaluation until a decision is made that the ruby version will be the SLE 12 one. + #6: Lukas Ocilka (locilka) (2013-07-30 14:31:47) (reply to #5) + Code is here: https://github.com/yast/yast-services-manager + And Ruby is set :) + Anyway, some parts are still missing... -- openSUSE Feature: https://features.opensuse.org/312568

1 0

[openFATE 313537] Get rid of SuSEconfig.glib2
by fate_noreply＠suse.de 19 Jul '13

19 Jul '13

Feature changed by: Frederic Crozat (fcrozat) Feature #313537, revision 7 Title: Get rid of SuSEconfig.glib2 - openSUSE Distribution: Evaluation by project manager + openSUSE Distribution: Done Priority Requester: Mandatory + Projectmanager: Mandatory Requested by: Andreas Jaeger (a_jaeger) Partner organization: openSUSE.org Description: There is no point to run that code after installation of every package (and it's not run when you use zypper or 3rd party tools anyways). That code should be only run as a part of post-install of the packages. Discussion: #1: Frederic Crozat (fcrozat) (2013-07-02 17:38:30) SuSEconfig being dead for SLE12, we could mark this feature as Done, already), but let's follow the process -- openSUSE Feature: https://features.opensuse.org/313537

1 0

[openFATE 302119] Load package selector and libzypp only when needed
by fate_noreply＠suse.de 19 Jul '13

19 Jul '13

Feature changed by: Andreas Jaeger (a_jaeger) Feature #302119, revision 48 Title: Load package selector and libzypp only when needed - openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) - reject date: 2007-08-01 16:40:54 - reject reason: Postponing. + openSUSE-10.3: Rejected by Andreas Jaeger (a_jaeger) + reject date: 2013-07-19 13:14:30 Priority Requester: Desirable Projectmanager: Important openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-04-28 13:42:30 reject reason: Did not make it, postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.1: Rejected Priority Requester: Desirable Projectmanager: Important openSUSE-11.2: Rejected by Stanislav Visnovsky (visnov) reject date: 2009-02-02 13:15:32 reject reason: Out of scope. Priority Requester: Desirable openSUSE-11.3: Rejected by Jiri Srain (jsrain) reject date: 2010-04-30 09:35:03 reject reason: Not done in time Priority Requester: Desirable Projectmanager: Important Requested by: Jiri Srain (jsrain) Partner organization: openSUSE.org Description: The YaST2 UI should load the code for the package selector and libzypp only when needed. Not all applications / YaST2 modules need package selection code, yet for all of them the respective code from the YaST2 UI and libzypp is loaded. Discussion: #1: Stefan Hundhammer (sh-sh-sh) (2007-04-13 18:13:44) In the YaST2 Qt the package management related code is now moved to a separate plugin that is loaded upon demand only if the calling YCP application actually requests a PackageSelector widget. This reduces the memory footprint from 20 MB VmRSS minimum (HelloWorld. ycp) to 18 MB minimum (PackageSelector-empty.ycp). #3: Katarina Machalkova (kmachalkova) (2007-04-16 14:41:35) Stano, do we want this for curses UI as well? If yes, than it's not 'done' ... #4: Stanislav Visnovsky (visnov) (2007-04-16 14:47:02) (reply to #3) Agreed. Reopening for ncurses and possibly gtk+. #5: Jiri Srain (jsrain) (2007-06-13 13:54:26) JP, both Qt and NCurses are done, but GTK is still missing. #6: Stefan Hundhammer (sh-sh-sh) (2007-06-13 15:08:58) Looks like yast2-pkg-bindings are also loaded unconditionally. It shouldn't be too hard to do that with "lazy initialization" like UI built-ins: Postpone loading the Y2Component until it's really needed. #7: Stanislav Visnovsky (visnov) (2007-06-19 15:01:54) (reply to #6) Jiri, if Pkg bindings problem is not addressed, it does not make sense to fix Gtk UI. #8: Jiri Srain (jsrain) (2007-07-18 13:59:50) (reply to #7) Sorry for missing this. Martin, please, solve this for the Pkg bindings. #10: Stanislav Visnovsky (visnov) (2007-11-08 11:38:22) (reply to #9) Please, follow up on this. #11: Martin Vidner (mvidner) (2008-04-10 15:23:51) yast2-perl-bindings-2.16.6 no longer links to libzypp, which means libzypp will not be loaded at the very start of yast (perl still will be loaded, but that is relatively cheap). That helps in some cases, but mostly it only delays loading of libzypp, which occurs as soon as Pkg (or Package) is imported. Now I need to make Pkg lazy. #12: Martin Vidner (mvidner) (2008-04-21 15:32:09) I have it almost working, but got stopped by bug 381917 (https://bugzilla.novell.com/show_bug.cgi?id=381917) : problems with destructors of static objects #13: JP Rosevear (jproseve) (2008-07-21 13:59:18) (reply to #12) Martin, what's the status here? Will we need to do anything explicit in packagekit to get this functionality? #14: Stanislav Visnovsky (visnov) (2008-09-08 16:44:06) (reply to #13) There is nothing regarding packagekit for this feature. -- openSUSE Feature: https://features.opensuse.org/302119

1 0

[openFATE 302119] Load package selector and libzypp only when needed
by fate_noreply＠suse.de 19 Jul '13

19 Jul '13

Feature changed by: Andreas Jaeger (a_jaeger) Feature #302119, revision 47 Title: Load package selector and libzypp only when needed openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-08-01 16:40:54 reject reason: Postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-04-28 13:42:30 reject reason: Did not make it, postponing. Priority Requester: Desirable Projectmanager: Important - openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) - reject date: 2008-09-12 14:13:58 - reject reason: Postponing. + openSUSE-11.1: Rejected Priority Requester: Desirable Projectmanager: Important openSUSE-11.2: Rejected by Stanislav Visnovsky (visnov) reject date: 2009-02-02 13:15:32 reject reason: Out of scope. Priority Requester: Desirable openSUSE-11.3: Rejected by Jiri Srain (jsrain) reject date: 2010-04-30 09:35:03 reject reason: Not done in time Priority Requester: Desirable Projectmanager: Important Requested by: Jiri Srain (jsrain) Partner organization: openSUSE.org Description: The YaST2 UI should load the code for the package selector and libzypp only when needed. Not all applications / YaST2 modules need package selection code, yet for all of them the respective code from the YaST2 UI and libzypp is loaded. Discussion: #1: Stefan Hundhammer (sh-sh-sh) (2007-04-13 18:13:44) In the YaST2 Qt the package management related code is now moved to a separate plugin that is loaded upon demand only if the calling YCP application actually requests a PackageSelector widget. This reduces the memory footprint from 20 MB VmRSS minimum (HelloWorld. ycp) to 18 MB minimum (PackageSelector-empty.ycp). #3: Katarina Machalkova (kmachalkova) (2007-04-16 14:41:35) Stano, do we want this for curses UI as well? If yes, than it's not 'done' ... #4: Stanislav Visnovsky (visnov) (2007-04-16 14:47:02) (reply to #3) Agreed. Reopening for ncurses and possibly gtk+. #5: Jiri Srain (jsrain) (2007-06-13 13:54:26) JP, both Qt and NCurses are done, but GTK is still missing. #6: Stefan Hundhammer (sh-sh-sh) (2007-06-13 15:08:58) Looks like yast2-pkg-bindings are also loaded unconditionally. It shouldn't be too hard to do that with "lazy initialization" like UI built-ins: Postpone loading the Y2Component until it's really needed. #7: Stanislav Visnovsky (visnov) (2007-06-19 15:01:54) (reply to #6) Jiri, if Pkg bindings problem is not addressed, it does not make sense to fix Gtk UI. #8: Jiri Srain (jsrain) (2007-07-18 13:59:50) (reply to #7) Sorry for missing this. Martin, please, solve this for the Pkg bindings. #10: Stanislav Visnovsky (visnov) (2007-11-08 11:38:22) (reply to #9) Please, follow up on this. #11: Martin Vidner (mvidner) (2008-04-10 15:23:51) yast2-perl-bindings-2.16.6 no longer links to libzypp, which means libzypp will not be loaded at the very start of yast (perl still will be loaded, but that is relatively cheap). That helps in some cases, but mostly it only delays loading of libzypp, which occurs as soon as Pkg (or Package) is imported. Now I need to make Pkg lazy. #12: Martin Vidner (mvidner) (2008-04-21 15:32:09) I have it almost working, but got stopped by bug 381917 (https://bugzilla.novell.com/show_bug.cgi?id=381917) : problems with destructors of static objects #13: JP Rosevear (jproseve) (2008-07-21 13:59:18) (reply to #12) Martin, what's the status here? Will we need to do anything explicit in packagekit to get this functionality? #14: Stanislav Visnovsky (visnov) (2008-09-08 16:44:06) (reply to #13) There is nothing regarding packagekit for this feature. -- openSUSE Feature: https://features.opensuse.org/302119

1 0

[New: openFATE 316097] Load package selector and libzypp only when needed
by fate_noreply＠suse.de 19 Jul '13

19 Jul '13

Feature added by: Matthias Eckermann (mge1512) Feature #316097, revision 1 Title: Load package selector and libzypp only when needed Requested by: Jiri Srain (jsrain) Partner organization: openSUSE.org Description: The YaST2 UI should load the code for the package selector and libzypp only when needed. Not all applications / YaST2 modules need package selection code, yet for all of them the respective code from the YaST2 UI and libzypp is loaded. -- openSUSE Feature: https://features.opensuse.org/316097

1 0

[openFATE 312568] YaST: add support for systemd service in runlevel editor
by fate_noreply＠suse.de 19 Jul '13

19 Jul '13

Feature changed by: Andreas Jaeger (a_jaeger) Feature #312568, revision 9 Title: YaST: add support for systemd service in runlevel editor openSUSE Distribution: Evaluation by project manager Priority Requester: Important Requested by: Frederic Crozat (fcrozat) Partner organization: openSUSE.org Description: Yast runlevel editor should be able to detect if systemd is running and allow to enable/disable systemd service (which can shadow some sysvinit services). Relations: - systemd adaptation of YaST (novell/bugzilla/id: https://bugzilla.novell.com/show_bug.cgi?id=664548) https://bugzilla.novell.com/show_bug.cgi?id=https://bugzilla.novell.com/sho… Discussion: #2: Frederic Crozat (fcrozat) (2012-01-06 11:27:40) YaST support (probably adding a service) should talk to systemd using D- Bus API (like it is already done in systemd gtk gui), so it won't have to handle merge of configuration and so on. #3: Andreas Jaeger (a_jaeger) (2013-07-19 11:14:53) Isn't this done already? #4: Frederic Crozat (fcrozat) (2013-07-19 11:33:27) (reply to #3) it is : http://kobliha-suse.blogspot.fr/2013/06/yast-runlevel-is-dead-long-live-yas… + #5: Andreas Jaeger (a_jaeger) (2013-07-19 11:35:51) (reply to #4) + Thanks - written in ruby. So, if we go to ruby, this is done. Thus not + marking yet as done but leaving it open for evaluation until a decision + is made that the ruby version will be the SLE 12 one. -- openSUSE Feature: https://features.opensuse.org/312568

1 0