December 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 300758] Show unneeded packages
by fate_noreply＠suse.de 15 Dec '09

15 Dec '09

Feature changed by: Don Hughes (dehughes) Feature #300758, revision 107 Title: Show unneeded packages openSUSE-10.2: Rejected by Thorsten Kukuk (kukuk) reject date: 2006-08-02 11:31:19 reject reason: For SL10.2 we have to get libzypp really stable and fast before we add new features. Priority Requester: Important openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-07-17 17:03:57 reject reason: Postponing. Priority Requester: Important Projectmanager: Desirable openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-11-21 12:16:20 reject reason: Out of scope for 11.0 Priority Requester: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-07 13:34:02 reject reason: Postponing, needs underlaying infrastructure to be fixed first. Priority Requester: Important openSUSE-11.2: Rejected by Stanislav Visnovsky (jkupec) reject date: 2009-11-30 14:20:26 reject reason: Marked as done by mistake. The feature is not done. Priority Requester: Important Projectmanager: Important openSUSE-11.3: New Priority Requester: Desirable Requested by: JP Rosevear (jproseve) Description: The package manager should learn to show unneeded packages (packages which are not required by other packages and are not in wanted selections) and allow to deinstall them like the popular debfoster/deborphan tools. A typical use case: user installs an application which pulls in some dependencies to test it, uninstalls the application shortly after or way later but the dependencies stay unused installed on the system. Commandline UI (zypper) only. References: https://bugzilla.novell.com/show_bug.cgi?id=166132 Discussion: #1: Jiri Srain (jsrain) (2007-06-05 13:46:00) Schubi, is there any possibility to make solver tell which packages are orphanized? It would be interesting especially if the packages which are marked for deletion were considered as non-installed (eg. if foo- devel is installed but marked for deletion and nothing else requires foo, then foo is orphanized). #2: Stefan Schubert (schubi2) (2007-06-06 11:04:04) (reply to #1) Currently not cause the solver has no information about who (user, package,...) has triggered the installation of a package. If we are storing this information it would be possible for solver to remove these kind of packages too. It is not simple but doable. By the way, we will have to store this kind of information in the future. E.g. we need to save the "keep state by user" in a database in order to regard this state in future solver runs. #3: Jiri Srain (jsrain) (2007-06-06 14:25:07) (reply to #2) Looks like a missunderstanding. Basically every package wihch is not required/recommended/suggested or doesn't enhance anything that is installed and not marked for deletion is IMO considered to be orphanized. If user eg. wants to remove a pattern including all its packages (which are not required by something else), solver providing this kind of information would help a lot (and I don't think that we would need any other information to be stored. #4: Stefan Schubert (schubi2) (2007-06-06 15:33:44) (reply to #3) I do not think so. What does "orphanized" mean ? Let me take your example from comment #1. foo should be deleted too if the user delete foo-devel and foo has been installed due the requirement of foo-devel. BUT the user will kill us if we are deleting foo although the user has installed foo explicit sometime ago in a seperate installation workflow. So this information ( The USER has installed foo) will be currently not saved and is needed here to decide if foo has to be deleted or not. #5: Stefan Schubert (schubi2) (2007-06-06 15:39:47) (reply to #3) Lets take your example concerning the erasing of patterns. That is much more complex. I have already described the problem here: http://en.opensuse.org/Libzypp/Solver#Known_Problems " Proper behaviour of erasing patterns" There are already some bugzilla entries: Bug 274283 - Delete iFolder from YaST makes eDirectory Delete mandatory Bug 238250 - YaST does not upgrade an Add-on Product #6: Jiri Srain (jsrain) (2007-06-08 16:46:32) See also https://bugzilla.novell.com/show_bug.cgi?id=166132 This is another use case for the same solver functionality #8: Federico Lucifredi (flucifredi) (2008-06-12 20:46:17) this should be commandline-only, definitely an advanced-user option. #9: Federico Lucifredi (flucifredi) (2008-06-12 20:47:28) cut from description: See Bug 140346 #10: Duncan Mac-Vicar (dmacvicar) (2008-11-03 11:24:53) As discussed in Prague, this could be done using the package history once we have a reader. #11: Karsten König (remur) (2009-01-19 10:09:49) How about using rpmorphan, I agree with flucifredi about the command line idea... http://rpmorphan.sourceforge.net/ And otherwise you could use their system to find orphanized packages and display them in yast but make clear that deleting -all orphanized packages will also delete the ones explicitly installed... (it only detects wether the package fullfiles any requirement...) #12: Ján Kupec (jkupec) (2009-01-19 14:48:38) (reply to #11) I'm not the solver developer, but i'm pretty sure it's easy (and probably more effective) to find the 'leaf' packages (that's what rpmorphan seems to do) using existing solver (see satsolver package). But we don't want to just highlight leaf packages, we want to remove unused packages, that is all leaves minus those explicitly installed. So we will feed the solver with this 'explicitly-installed' information. The package history will be the source of this info for now. Maybe later we find some way to store this info that could be used across tools (e.g. directly in the rpm db). So rpmorphan will be able to use this info as well. #13: Pavol Rusnak (prusnak) (2009-01-19 15:44:26) (reply to #12) Yes, that's good idea. Detecting leaf packages is the first step. Detecting which ones to remove (i.e. not explicitly installed) is the second. I think that rpmorphan shows all leaf packages, but it selects only the ones that start with "lib". If we strictly followed library packaging policy that would do the trick. btw. rpmorphan is packaged in Contrib (http://en.opensuse.org/Contrib) #14: Michal Smrž (ilfirin) (2009-03-07 20:05:22) (reply to #11) I am afraid of using rpmorphan to do this. Cause last time, I tested it, it wants to remove libdvdnav and libdvdcss libraries. This is very bad. It leads to many not advanced users to ask in phorums "Why OpenSUSE is not playing DVDs anymore?" I see many problems this could make. #15: Christoph Thiel (cthiel1) (2009-04-21 15:23:06) We don't have the resources to implementing this. Seems to be a prefect fit for a community project. #17: Piotrek Juzwiak (benderbendingrodriguez) (2009-04-22 07:58:47) Maybe the idea to accomplish this would be simply by using the packages. xml file and diff it. We can already export what packages we got right? So if it would compare the packages.xml before installation and after it would then delete it. There is a problem when installing many packages, they would all have to be "grouped" which pulled which dependencies. #20: Vladimirs Kuzmins (vovachaka) (2009-10-26 16:27:51) This feature is a specially important, now when we have distro upgrade, which changes a lot of dependencies and a lot of obsolete packages remain installed. Please, someone implement it! #21: Thomas Göttlicher (tgoettlicher) (2009-10-26 16:41:29) I've added a view for orphaned packages in yast2-qt-pkg. There is a package group "orphaned packages" similar to "suggested packages" and "recommended packages" in yast2-qt-pkg version 2.18.17. #22: Atri Bhattacharya (badshah400) (2009-10-31 14:55:26) (reply to #21) Thanks for implementing this much needed feature. But this feature does not work with the gtk interface in 11.2 RC2; please have this added for the final release of 11.2. #23: Kornél Jahn (cornail) (2009-11-02 07:48:05) (reply to #21) Tried to test this but didn't seem to work on RC2: Orphaned packages view is empty. E.g. installed blender, which pulled yafray. After uninstalling blender, yafray remained installed but didn't show up as an orphaned package. Also installing audacity or inkscape pulled a lot of dependencies which were not showed as orphaned after uninstalling them. #24: Kornél Jahn (cornail) (2009-11-02 08:06:38) (reply to #23) Since it is marked as done, I filed a bug for it: https://bugzilla.novell.com/show_bug.cgi?id=551771 (https://bugzilla.novell.com/show_bug.cgi?id=551771) #25: Ján Kupec (jkupec) (2009-11-30 14:18:55) (reply to #21) There has been a misunderstanding here. What Thomas implemented is a view of packages that no longer have update candidates (those which are probably no longer maintained, thus 'orphaned'). This very fate request (IMO) incorrectly uses the word 'orphaned' for what is better described as "unused packages" or "no longer needed packages", or "unnecessary packages". Definitely not orphans (deborphan/rpmorphan is also a misfortunate name IMO). Anyway, whether orphan or unused, this feature is not implemented yet, thus i'm reopening it for 11.3. #26: Ján Kupec (jkupec) (2009-11-30 14:21:27) reopening for 11.3 (see comment #25) #27: Ján Kupec (jkupec) (2009-11-30 14:30:44) I suggest to call these packages unused instead of orphaned . I don't want to decide this by myself, so please speak up. Here are my arguments: 1) the word 'orphan' describes something that has lost its parent(s). In this case, it is actually the child that was lost - a package that depended on other package has been removed. The parent package is still installed, but there's no more use for it - it's unused . 2) we (and a few other distros and communities as well) already use orphaned to describe packages that are no longer cared for - unmaintained packages, packages dropped from distros. #28: Ján Kupec (jkupec) (2009-11-30 15:05:21) (reply to #27) Thomas suggests that perhaps not needed (or no longer needed ) would be better than unused since 'unused' can be confused with 'not used by user' rather than 'not used by other packages'. #29: Roberto Mannai (robermann79) (2009-11-30 15:40:37) Undependent packages : packages which don't have any(more) dependency. #30: Kornél Jahn (cornail) (2009-11-30 16:15:08) I also support the not needed / no longer needed version. Orphaned is bad since it can be misunderstood, just like "undependent package", if Roberto meant to suggest it as a description for this phenomenon. Case A: If I install manually package X, which doesn't have any dependencies nor is it referred to by any other package, it is not a "not needed" one. 'Cause it was manually installed by the user. Case B: Package X is installed automatically as a dependency while installing package Y. Package Y is then removed, but X stays, with no other package referring to it as a dependency. X is then a "not needed" package. #31: Roberto Mannai (robermann79) (2009-11-30 17:00:02) (reply to #30) +1 Kornél Regarding Case A: of course "not needed package" is a subset "undependent package" - "not needed" catches the user's point of view and it is more precise. Nevertheless, determining that "not needed" packages is a hard job, so it could be a good starting point just knowing which are the "undependent" ones (at least as a first step). #32: Roberto Mannai (robermann79) (2009-11-30 17:47:05) (reply to #31) The user could have a graphical list of "undependent packages", which then he could mark each of them as "used/not used". The GUI then could suggest the "unused packages" for removal (this being a temporary but useful use case). #33: Ken Schneider (kensch) (2009-12-15 18:15:55) When you install a package using package management it checks to make sure all dependencies are also installed or adds them to the install list via the "Requires" feature. When de-installing the package check the list of "Requires" packages and see which ones can also be de- installed. That way there are no left over packages. If one of the "Requires" packages are also needed by other packages they are left installed. I am no where near being a programmer but that would seem to be simple to do. #34: Ján Kupec (jkupec) (2009-12-15 18:47:57) (reply to #33) Such procedure would also wipe out packages that you still want to use. E.g. you have nagios-plugins-zypper, which requires zypper. Now, 'zypper remove nagios-plugins-zypper' would realize that after removing nagios-plugins-zypper nothing requires zypper, and would want to remove zypper as well. So what your idea lacks is a list of packages that were installed in the past based on explicit request by user. The procedure must avoid removing these. See also c#12 #36: Ján Kupec (jkupec) (2009-12-15 18:47:02) So i'm renaming this fate request to 'Show unneeded packages' (to make it shorter) to avoid further confustion. + #37: Don Hughes (dehughes) (2009-12-15 19:10:53) + I also would like to see this feature. I currently use rpmorphan with + a list of things that it will mark that I know that I need. I also + occationally go through yast2 and try to uninstall things that I do not + recognize and see if they are flagged as being needed by something + else. Both time consuming and error prone. + And, a lot of packages seem to be some what careless in what the + require for prereqs - pulling in KDE,gnome, and X11 packages on text- + only machines for example; which then triggers a flood of KDE, gnome, + and X11 library installations which I then have to mannually uninstall + and mark as taboo. + On my external facing servers I do not like to have any + extra/unneeded/unwanted packages to provide possible attack vectors. + -- openSUSE Feature: https://features.opensuse.org/300758

1 0

[openFATE 300758] Show unneeded packages
by fate_noreply＠suse.de 15 Dec '09

15 Dec '09

Feature changed by: Ján Kupec (jkupec) Feature #300758, revision 106 - Title: Show orphaned packages + Title: Show unneeded packages openSUSE-10.2: Rejected by Thorsten Kukuk (kukuk) reject date: 2006-08-02 11:31:19 reject reason: For SL10.2 we have to get libzypp really stable and fast before we add new features. Priority Requester: Important openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-07-17 17:03:57 reject reason: Postponing. Priority Requester: Important Projectmanager: Desirable openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-11-21 12:16:20 reject reason: Out of scope for 11.0 Priority Requester: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-07 13:34:02 reject reason: Postponing, needs underlaying infrastructure to be fixed first. Priority Requester: Important openSUSE-11.2: Rejected by Stanislav Visnovsky (jkupec) reject date: 2009-11-30 14:20:26 reject reason: Marked as done by mistake. The feature is not done. Priority Requester: Important Projectmanager: Important openSUSE-11.3: New Priority Requester: Desirable Requested by: JP Rosevear (jproseve) Description: - The package manager should learn to show orphanized packages (packages + The package manager should learn to show unneeded packages (packages which are not required by other packages and are not in wanted selections) and allow to deinstall them like the popular debfoster/deborphan tools. A typical use case: user installs an application which pulls in some dependencies to test it, uninstalls the application shortly after or way later but the dependencies stay unused installed on the system. Commandline UI (zypper) only. References: https://bugzilla.novell.com/show_bug.cgi?id=166132 Discussion: #1: Jiri Srain (jsrain) (2007-06-05 13:46:00) Schubi, is there any possibility to make solver tell which packages are orphanized? It would be interesting especially if the packages which are marked for deletion were considered as non-installed (eg. if foo- devel is installed but marked for deletion and nothing else requires foo, then foo is orphanized). #2: Stefan Schubert (schubi2) (2007-06-06 11:04:04) (reply to #1) Currently not cause the solver has no information about who (user, package,...) has triggered the installation of a package. If we are storing this information it would be possible for solver to remove these kind of packages too. It is not simple but doable. By the way, we will have to store this kind of information in the future. E.g. we need to save the "keep state by user" in a database in order to regard this state in future solver runs. #3: Jiri Srain (jsrain) (2007-06-06 14:25:07) (reply to #2) Looks like a missunderstanding. Basically every package wihch is not required/recommended/suggested or doesn't enhance anything that is installed and not marked for deletion is IMO considered to be orphanized. If user eg. wants to remove a pattern including all its packages (which are not required by something else), solver providing this kind of information would help a lot (and I don't think that we would need any other information to be stored. #4: Stefan Schubert (schubi2) (2007-06-06 15:33:44) (reply to #3) I do not think so. What does "orphanized" mean ? Let me take your example from comment #1. foo should be deleted too if the user delete foo-devel and foo has been installed due the requirement of foo-devel. BUT the user will kill us if we are deleting foo although the user has installed foo explicit sometime ago in a seperate installation workflow. So this information ( The USER has installed foo) will be currently not saved and is needed here to decide if foo has to be deleted or not. #5: Stefan Schubert (schubi2) (2007-06-06 15:39:47) (reply to #3) Lets take your example concerning the erasing of patterns. That is much more complex. I have already described the problem here: http://en.opensuse.org/Libzypp/Solver#Known_Problems " Proper behaviour of erasing patterns" There are already some bugzilla entries: Bug 274283 - Delete iFolder from YaST makes eDirectory Delete mandatory Bug 238250 - YaST does not upgrade an Add-on Product #6: Jiri Srain (jsrain) (2007-06-08 16:46:32) See also https://bugzilla.novell.com/show_bug.cgi?id=166132 This is another use case for the same solver functionality #8: Federico Lucifredi (flucifredi) (2008-06-12 20:46:17) this should be commandline-only, definitely an advanced-user option. #9: Federico Lucifredi (flucifredi) (2008-06-12 20:47:28) cut from description: See Bug 140346 #10: Duncan Mac-Vicar (dmacvicar) (2008-11-03 11:24:53) As discussed in Prague, this could be done using the package history once we have a reader. #11: Karsten König (remur) (2009-01-19 10:09:49) How about using rpmorphan, I agree with flucifredi about the command line idea... http://rpmorphan.sourceforge.net/ And otherwise you could use their system to find orphanized packages and display them in yast but make clear that deleting -all orphanized packages will also delete the ones explicitly installed... (it only detects wether the package fullfiles any requirement...) #12: Ján Kupec (jkupec) (2009-01-19 14:48:38) (reply to #11) I'm not the solver developer, but i'm pretty sure it's easy (and probably more effective) to find the 'leaf' packages (that's what rpmorphan seems to do) using existing solver (see satsolver package). But we don't want to just highlight leaf packages, we want to remove unused packages, that is all leaves minus those explicitly installed. So we will feed the solver with this 'explicitly-installed' information. The package history will be the source of this info for now. Maybe later we find some way to store this info that could be used across tools (e.g. directly in the rpm db). So rpmorphan will be able to use this info as well. #13: Pavol Rusnak (prusnak) (2009-01-19 15:44:26) (reply to #12) Yes, that's good idea. Detecting leaf packages is the first step. Detecting which ones to remove (i.e. not explicitly installed) is the second. I think that rpmorphan shows all leaf packages, but it selects only the ones that start with "lib". If we strictly followed library packaging policy that would do the trick. btw. rpmorphan is packaged in Contrib (http://en.opensuse.org/Contrib) #14: Michal Smrž (ilfirin) (2009-03-07 20:05:22) (reply to #11) I am afraid of using rpmorphan to do this. Cause last time, I tested it, it wants to remove libdvdnav and libdvdcss libraries. This is very bad. It leads to many not advanced users to ask in phorums "Why OpenSUSE is not playing DVDs anymore?" I see many problems this could make. #15: Christoph Thiel (cthiel1) (2009-04-21 15:23:06) We don't have the resources to implementing this. Seems to be a prefect fit for a community project. #17: Piotrek Juzwiak (benderbendingrodriguez) (2009-04-22 07:58:47) Maybe the idea to accomplish this would be simply by using the packages. xml file and diff it. We can already export what packages we got right? So if it would compare the packages.xml before installation and after it would then delete it. There is a problem when installing many packages, they would all have to be "grouped" which pulled which dependencies. #20: Vladimirs Kuzmins (vovachaka) (2009-10-26 16:27:51) This feature is a specially important, now when we have distro upgrade, which changes a lot of dependencies and a lot of obsolete packages remain installed. Please, someone implement it! #21: Thomas Göttlicher (tgoettlicher) (2009-10-26 16:41:29) I've added a view for orphaned packages in yast2-qt-pkg. There is a package group "orphaned packages" similar to "suggested packages" and "recommended packages" in yast2-qt-pkg version 2.18.17. #22: Atri Bhattacharya (badshah400) (2009-10-31 14:55:26) (reply to #21) Thanks for implementing this much needed feature. But this feature does not work with the gtk interface in 11.2 RC2; please have this added for the final release of 11.2. #23: Kornél Jahn (cornail) (2009-11-02 07:48:05) (reply to #21) Tried to test this but didn't seem to work on RC2: Orphaned packages view is empty. E.g. installed blender, which pulled yafray. After uninstalling blender, yafray remained installed but didn't show up as an orphaned package. Also installing audacity or inkscape pulled a lot of dependencies which were not showed as orphaned after uninstalling them. #24: Kornél Jahn (cornail) (2009-11-02 08:06:38) (reply to #23) Since it is marked as done, I filed a bug for it: https://bugzilla.novell.com/show_bug.cgi?id=551771 (https://bugzilla.novell.com/show_bug.cgi?id=551771) #25: Ján Kupec (jkupec) (2009-11-30 14:18:55) (reply to #21) There has been a misunderstanding here. What Thomas implemented is a view of packages that no longer have update candidates (those which are probably no longer maintained, thus 'orphaned'). This very fate request (IMO) incorrectly uses the word 'orphaned' for what is better described as "unused packages" or "no longer needed packages", or "unnecessary packages". Definitely not orphans (deborphan/rpmorphan is also a misfortunate name IMO). Anyway, whether orphan or unused, this feature is not implemented yet, thus i'm reopening it for 11.3. #26: Ján Kupec (jkupec) (2009-11-30 14:21:27) reopening for 11.3 (see comment #25) #27: Ján Kupec (jkupec) (2009-11-30 14:30:44) I suggest to call these packages unused instead of orphaned . I don't want to decide this by myself, so please speak up. Here are my arguments: 1) the word 'orphan' describes something that has lost its parent(s). In this case, it is actually the child that was lost - a package that depended on other package has been removed. The parent package is still installed, but there's no more use for it - it's unused . 2) we (and a few other distros and communities as well) already use orphaned to describe packages that are no longer cared for - unmaintained packages, packages dropped from distros. #28: Ján Kupec (jkupec) (2009-11-30 15:05:21) (reply to #27) Thomas suggests that perhaps not needed (or no longer needed ) would be better than unused since 'unused' can be confused with 'not used by user' rather than 'not used by other packages'. #29: Roberto Mannai (robermann79) (2009-11-30 15:40:37) Undependent packages : packages which don't have any(more) dependency. #30: Kornél Jahn (cornail) (2009-11-30 16:15:08) I also support the not needed / no longer needed version. Orphaned is bad since it can be misunderstood, just like "undependent package", if Roberto meant to suggest it as a description for this phenomenon. Case A: If I install manually package X, which doesn't have any dependencies nor is it referred to by any other package, it is not a "not needed" one. 'Cause it was manually installed by the user. Case B: Package X is installed automatically as a dependency while installing package Y. Package Y is then removed, but X stays, with no other package referring to it as a dependency. X is then a "not needed" package. #31: Roberto Mannai (robermann79) (2009-11-30 17:00:02) (reply to #30) +1 Kornél Regarding Case A: of course "not needed package" is a subset "undependent package" - "not needed" catches the user's point of view and it is more precise. Nevertheless, determining that "not needed" packages is a hard job, so it could be a good starting point just knowing which are the "undependent" ones (at least as a first step). #32: Roberto Mannai (robermann79) (2009-11-30 17:47:05) (reply to #31) The user could have a graphical list of "undependent packages", which then he could mark each of them as "used/not used". The GUI then could suggest the "unused packages" for removal (this being a temporary but useful use case). #33: Ken Schneider (kensch) (2009-12-15 18:15:55) When you install a package using package management it checks to make sure all dependencies are also installed or adds them to the install list via the "Requires" feature. When de-installing the package check the list of "Requires" packages and see which ones can also be de- installed. That way there are no left over packages. If one of the "Requires" packages are also needed by other packages they are left installed. I am no where near being a programmer but that would seem to be simple to do. + #34: Ján Kupec (jkupec) (2009-12-15 18:47:57) (reply to #33) + Such procedure would also wipe out packages that you still want to use. + E.g. you have nagios-plugins-zypper, which requires zypper. Now, + 'zypper remove nagios-plugins-zypper' would realize that after removing + nagios-plugins-zypper nothing requires zypper, and would want to remove + zypper as well. + So what your idea lacks is a list of packages that were installed in + the past based on explicit request by user. The procedure must avoid + removing these. + See also c#12 + #36: Ján Kupec (jkupec) (2009-12-15 18:47:02) + So i'm renaming this fate request to 'Show unneeded packages' (to make + it shorter) to avoid further confustion. -- openSUSE Feature: https://features.opensuse.org/300758

1 0

[openFATE 300758] Show orphaned packages
by fate_noreply＠suse.de 15 Dec '09

15 Dec '09

Feature changed by: Ken Schneider (kensch) Feature #300758, revision 105 Title: Show orphaned packages openSUSE-10.2: Rejected by Thorsten Kukuk (kukuk) reject date: 2006-08-02 11:31:19 reject reason: For SL10.2 we have to get libzypp really stable and fast before we add new features. Priority Requester: Important openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-07-17 17:03:57 reject reason: Postponing. Priority Requester: Important Projectmanager: Desirable openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-11-21 12:16:20 reject reason: Out of scope for 11.0 Priority Requester: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-07 13:34:02 reject reason: Postponing, needs underlaying infrastructure to be fixed first. Priority Requester: Important openSUSE-11.2: Rejected by Stanislav Visnovsky (jkupec) reject date: 2009-11-30 14:20:26 reject reason: Marked as done by mistake. The feature is not done. Priority Requester: Important Projectmanager: Important openSUSE-11.3: New Priority Requester: Desirable Requested by: JP Rosevear (jproseve) Description: The package manager should learn to show orphanized packages (packages which are not required by other packages and are not in wanted selections) and allow to deinstall them like the popular debfoster/deborphan tools. A typical use case: user installs an application which pulls in some dependencies to test it, uninstalls the application shortly after or way later but the dependencies stay unused installed on the system. Commandline UI (zypper) only. References: https://bugzilla.novell.com/show_bug.cgi?id=166132 Discussion: #1: Jiri Srain (jsrain) (2007-06-05 13:46:00) Schubi, is there any possibility to make solver tell which packages are orphanized? It would be interesting especially if the packages which are marked for deletion were considered as non-installed (eg. if foo- devel is installed but marked for deletion and nothing else requires foo, then foo is orphanized). #2: Stefan Schubert (schubi2) (2007-06-06 11:04:04) (reply to #1) Currently not cause the solver has no information about who (user, package,...) has triggered the installation of a package. If we are storing this information it would be possible for solver to remove these kind of packages too. It is not simple but doable. By the way, we will have to store this kind of information in the future. E.g. we need to save the "keep state by user" in a database in order to regard this state in future solver runs. #3: Jiri Srain (jsrain) (2007-06-06 14:25:07) (reply to #2) Looks like a missunderstanding. Basically every package wihch is not required/recommended/suggested or doesn't enhance anything that is installed and not marked for deletion is IMO considered to be orphanized. If user eg. wants to remove a pattern including all its packages (which are not required by something else), solver providing this kind of information would help a lot (and I don't think that we would need any other information to be stored. #4: Stefan Schubert (schubi2) (2007-06-06 15:33:44) (reply to #3) I do not think so. What does "orphanized" mean ? Let me take your example from comment #1. foo should be deleted too if the user delete foo-devel and foo has been installed due the requirement of foo-devel. BUT the user will kill us if we are deleting foo although the user has installed foo explicit sometime ago in a seperate installation workflow. So this information ( The USER has installed foo) will be currently not saved and is needed here to decide if foo has to be deleted or not. #5: Stefan Schubert (schubi2) (2007-06-06 15:39:47) (reply to #3) Lets take your example concerning the erasing of patterns. That is much more complex. I have already described the problem here: http://en.opensuse.org/Libzypp/Solver#Known_Problems " Proper behaviour of erasing patterns" There are already some bugzilla entries: Bug 274283 - Delete iFolder from YaST makes eDirectory Delete mandatory Bug 238250 - YaST does not upgrade an Add-on Product #6: Jiri Srain (jsrain) (2007-06-08 16:46:32) See also https://bugzilla.novell.com/show_bug.cgi?id=166132 This is another use case for the same solver functionality #8: Federico Lucifredi (flucifredi) (2008-06-12 20:46:17) this should be commandline-only, definitely an advanced-user option. #9: Federico Lucifredi (flucifredi) (2008-06-12 20:47:28) cut from description: See Bug 140346 #10: Duncan Mac-Vicar (dmacvicar) (2008-11-03 11:24:53) As discussed in Prague, this could be done using the package history once we have a reader. #11: Karsten König (remur) (2009-01-19 10:09:49) How about using rpmorphan, I agree with flucifredi about the command line idea... http://rpmorphan.sourceforge.net/ And otherwise you could use their system to find orphanized packages and display them in yast but make clear that deleting -all orphanized packages will also delete the ones explicitly installed... (it only detects wether the package fullfiles any requirement...) #12: Ján Kupec (jkupec) (2009-01-19 14:48:38) (reply to #11) I'm not the solver developer, but i'm pretty sure it's easy (and probably more effective) to find the 'leaf' packages (that's what rpmorphan seems to do) using existing solver (see satsolver package). But we don't want to just highlight leaf packages, we want to remove unused packages, that is all leaves minus those explicitly installed. So we will feed the solver with this 'explicitly-installed' information. The package history will be the source of this info for now. Maybe later we find some way to store this info that could be used across tools (e.g. directly in the rpm db). So rpmorphan will be able to use this info as well. #13: Pavol Rusnak (prusnak) (2009-01-19 15:44:26) (reply to #12) Yes, that's good idea. Detecting leaf packages is the first step. Detecting which ones to remove (i.e. not explicitly installed) is the second. I think that rpmorphan shows all leaf packages, but it selects only the ones that start with "lib". If we strictly followed library packaging policy that would do the trick. btw. rpmorphan is packaged in Contrib (http://en.opensuse.org/Contrib) #14: Michal Smrž (ilfirin) (2009-03-07 20:05:22) (reply to #11) I am afraid of using rpmorphan to do this. Cause last time, I tested it, it wants to remove libdvdnav and libdvdcss libraries. This is very bad. It leads to many not advanced users to ask in phorums "Why OpenSUSE is not playing DVDs anymore?" I see many problems this could make. #15: Christoph Thiel (cthiel1) (2009-04-21 15:23:06) We don't have the resources to implementing this. Seems to be a prefect fit for a community project. #17: Piotrek Juzwiak (benderbendingrodriguez) (2009-04-22 07:58:47) Maybe the idea to accomplish this would be simply by using the packages. xml file and diff it. We can already export what packages we got right? So if it would compare the packages.xml before installation and after it would then delete it. There is a problem when installing many packages, they would all have to be "grouped" which pulled which dependencies. #20: Vladimirs Kuzmins (vovachaka) (2009-10-26 16:27:51) This feature is a specially important, now when we have distro upgrade, which changes a lot of dependencies and a lot of obsolete packages remain installed. Please, someone implement it! #21: Thomas Göttlicher (tgoettlicher) (2009-10-26 16:41:29) I've added a view for orphaned packages in yast2-qt-pkg. There is a package group "orphaned packages" similar to "suggested packages" and "recommended packages" in yast2-qt-pkg version 2.18.17. #22: Atri Bhattacharya (badshah400) (2009-10-31 14:55:26) (reply to #21) Thanks for implementing this much needed feature. But this feature does not work with the gtk interface in 11.2 RC2; please have this added for the final release of 11.2. #23: Kornél Jahn (cornail) (2009-11-02 07:48:05) (reply to #21) Tried to test this but didn't seem to work on RC2: Orphaned packages view is empty. E.g. installed blender, which pulled yafray. After uninstalling blender, yafray remained installed but didn't show up as an orphaned package. Also installing audacity or inkscape pulled a lot of dependencies which were not showed as orphaned after uninstalling them. #24: Kornél Jahn (cornail) (2009-11-02 08:06:38) (reply to #23) Since it is marked as done, I filed a bug for it: https://bugzilla.novell.com/show_bug.cgi?id=551771 (https://bugzilla.novell.com/show_bug.cgi?id=551771) #25: Ján Kupec (jkupec) (2009-11-30 14:18:55) (reply to #21) There has been a misunderstanding here. What Thomas implemented is a view of packages that no longer have update candidates (those which are probably no longer maintained, thus 'orphaned'). This very fate request (IMO) incorrectly uses the word 'orphaned' for what is better described as "unused packages" or "no longer needed packages", or "unnecessary packages". Definitely not orphans (deborphan/rpmorphan is also a misfortunate name IMO). Anyway, whether orphan or unused, this feature is not implemented yet, thus i'm reopening it for 11.3. #26: Ján Kupec (jkupec) (2009-11-30 14:21:27) reopening for 11.3 (see comment #25) #27: Ján Kupec (jkupec) (2009-11-30 14:30:44) I suggest to call these packages unused instead of orphaned . I don't want to decide this by myself, so please speak up. Here are my arguments: 1) the word 'orphan' describes something that has lost its parent(s). In this case, it is actually the child that was lost - a package that depended on other package has been removed. The parent package is still installed, but there's no more use for it - it's unused . 2) we (and a few other distros and communities as well) already use orphaned to describe packages that are no longer cared for - unmaintained packages, packages dropped from distros. #28: Ján Kupec (jkupec) (2009-11-30 15:05:21) (reply to #27) Thomas suggests that perhaps not needed (or no longer needed ) would be better than unused since 'unused' can be confused with 'not used by user' rather than 'not used by other packages'. #29: Roberto Mannai (robermann79) (2009-11-30 15:40:37) Undependent packages : packages which don't have any(more) dependency. #30: Kornél Jahn (cornail) (2009-11-30 16:15:08) I also support the not needed / no longer needed version. Orphaned is bad since it can be misunderstood, just like "undependent package", if Roberto meant to suggest it as a description for this phenomenon. Case A: If I install manually package X, which doesn't have any dependencies nor is it referred to by any other package, it is not a "not needed" one. 'Cause it was manually installed by the user. Case B: Package X is installed automatically as a dependency while installing package Y. Package Y is then removed, but X stays, with no other package referring to it as a dependency. X is then a "not needed" package. #31: Roberto Mannai (robermann79) (2009-11-30 17:00:02) (reply to #30) +1 Kornél Regarding Case A: of course "not needed package" is a subset "undependent package" - "not needed" catches the user's point of view and it is more precise. Nevertheless, determining that "not needed" packages is a hard job, so it could be a good starting point just knowing which are the "undependent" ones (at least as a first step). #32: Roberto Mannai (robermann79) (2009-11-30 17:47:05) (reply to #31) The user could have a graphical list of "undependent packages", which then he could mark each of them as "used/not used". The GUI then could suggest the "unused packages" for removal (this being a temporary but useful use case). + #33: Ken Schneider (kensch) (2009-12-15 18:15:55) + When you install a package using package management it checks to make + sure all dependencies are also installed or adds them to the install + list via the "Requires" feature. When de-installing the package check + the list of "Requires" packages and see which ones can also be de- + installed. That way there are no left over packages. If one of the + "Requires" packages are also needed by other packages they are left + installed. I am no where near being a programmer but that would seem to + be simple to do. -- openSUSE Feature: https://features.opensuse.org/300758

1 0

[New: openFATE 308479] Smart card support module yast2
by fate_noreply＠suse.de 15 Dec '09

15 Dec '09

Feature added by: Erik Winands (ewinands) Feature #308479, revision 1 Title: Smart card support module yast2 openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Erik Winands (ewinands) Description: I would be nice to add a smart cart install/config module to the yast2 interface. -- openSUSE Feature: https://features.opensuse.org/308479

1 1

[New: openFATE 308490] Parameterize LVM System Disk
by fate_noreply＠suse.de 15 Dec '09

15 Dec '09

Feature added by: Andreas Jaeger (a_jaeger) Feature #308490, revision 1 Title: Parameterize LVM System Disk openSUSE-11.3: Evaluation Priority Requester: Mandatory Requested by: Andreas Jaeger (a_jaeger) Description: We are currently limiting with LVM setup the size of the LVM System to 20 GB since it's required for some products. This is not desired for openSUSE and we should add a parameter to control.xml (or wherever) that parameterizes this so that for openSUSE we use the full disk. Relations: - Automatic creation of encrypted root is broken (novell/bugzilla/id: 0) https://bugzilla.novell.com/show_bug.cgi?id=0 -- openSUSE Feature: https://features.opensuse.org/308490

1 5

[New: openFATE 308463] add FreeIPMI
by fate_noreply＠suse.de 12 Dec '09

12 Dec '09

Feature added by: Al Chu (chu11) Feature #308463, revision 1 Title: add FreeIPMI Package Wishlist: Unconfirmed Priority Requester: Desirable Requested by: Al Chu (chu11) Partner organization: openSUSE.org Description: FreeIPMI is a collection of tools and libraries for IPMI system management (see IPMI at http://www.intel.com/design/servers/ipmi/). Business case (Partner benefit): openSUSE.org: At a glance, FreeIPMI may be viewed very similarly to (or possibly overlapping) w/ the openipmi and ipmitool packages, however it offers a number of features that are superior for HPC or large cluster/data center environments not provided by the other packages. In addition, it offers additional support and features on a number of motherboards that currently aren't supported by openipmi or ipmitool. -- openSUSE Feature: https://features.opensuse.org/308463

1 3

[openFATE 305317] Default to hidden bootloader menu
by fate_noreply＠suse.de 12 Dec '09

12 Dec '09

Feature changed by: Jan Engelhardt (jengelh) Feature #305317, revision 24 Title: Default to hidden bootloader menu openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-08-05 12:17:52 reject reason: out of resources for 11.2. Priority Requester: Desirable Projectmanager: Desirable openSUSE-11.3: New Priority Requester: Desirable Info Provider: Jan Engelhardt (jengelh) Requested by: Jiri Srain (jsrain) Description: As long as there is no other operating system present (SUSE is the only system), it makes sense to default to hidden bootloader menu (and booting directly). References: http://www.gnu.org/software/grub/manual/grub.html#Hidden-menu-interface https://bugzilla.novell.com/show_bug.cgi?id=425717 Discussion: #1: Stephan Kulow (coolo) (2009-04-16 10:34:48) I like that idea. I guess it's a tiny change for bootloader, but has possibly some docu impact. #2: Stanislav Visnovsky (visnov) (2009-05-28 16:45:13) How should it behave with option to keep kernels from updates (libzypp option)? What about failsafe? #3: Jiri Srain (jsrain) (2009-06-01 11:21:11) From the GRUB documentation: When your terminal is dumb or you request GRUB to hide the menu interface explicitly with the command `hiddenmenu' (*note hiddenmenu::), GRUB doesn't show the menu interface (*note Menu interface::) and automatically boots the default entry, unless interrupted by pressing ESC. When you interrupt the timeout and your terminal is dumb, GRUB falls back to the command-line interface (*note Command-line interface::). This sounds to me like this GRUB feature is intended for different purpose, and the use case described here does not make much sense (unlike lowering the time-out to e.g. 1 second). Torsten, what is your view? According to the documentation, GRUB allows to display the boot menu via pushing the Escape button. #7: Christoph Thiel (cthiel1) (2009-07-16 11:27:26) (reply to #3) Torsten, could you please provide your view on this? Fedora and others seem to be doing this for years. #4: T. J. Brumfield (enderandrew) (2009-06-13 03:31:06) This option would only be utilized when no other OS is present, and you can still get back to the menu with Esc. This isn't that much different than needing F8 for the boot menu for Windows. It would speed up boot times. How is that a bad thing? #5: Jan Engelhardt (jengelh) (2009-06-18 23:53:45) Does not Fedora do something similar? #6: Christoph Thiel (cthiel1) (2009-06-28 10:00:44) (reply to #5) I haven't looked at how Fedora handles this. Jan, would you be able to dig into what Fedora does technically? This would be very much appreciated! #9: Jan Engelhardt (jengelh) (2009-08-09 14:38:47) (reply to #6) (Well I had hoped you know ;-) What Fedora does (or what it used to in the last years, or what other distros did/do) is that the first GRUB screen does not show the menu (it's "hidden"), but only shows it if you interrupt with a keypress: http://www.dedoimedo.com/images/computers/fedora-first-boot.jpg --1st screen with "HIDDEN MENU" http://fedoraproject.org/w/uploads/d/d4/Tours_Fedora9_001_Install_Boot.png -- 2nd screen And FWIW, I find that rather pointless, just show the menu, does not hurt anybody to know a bit more about one's own system. #8: Stefan Kunze (kunzes) (2009-07-28 16:03:50) The only problem I see with this is when the installer does not pick up another installed OS (happens to Windows once in a while) and defaults to a hidden Bootloader? #10: Robert Davies (robopensuse) (2009-12-10 17:53:20) GRUB2 defaults to this method. How does this speed boot time though? If you wait for the user to give them a chance to activate the Hidden menu, you actually slow things up, as they are not encouraged to hit <enter>. I think having option hidden, makes it less obvious and increases documentation and support workload, because greater need for user education. Also the kernel does not give good user feedback early in boot process, seeing menu flash up reassures end user that things are working as expected. + #11: Jan Engelhardt (jengelh) (2009-12-12 14:29:27) (reply to #10) + Indeed, the switch time from the hidden state to showing the menu + entries is considerable (and part of that is because it uses VESA). + GRUB's text mode hidden feature (for serial consoles) is faster ;) -- openSUSE Feature: https://features.opensuse.org/305317

1 0

[openFATE 306476] Install boot entry configurable in kernel git file
by fate_noreply＠suse.de 12 Dec '09

12 Dec '09

Feature changed by: Stefan Dirsch (sndirsch) Feature #306476, revision 16 Title: Install boot entry configurable in kernel git file openSUSE-11.2: Evaluation Priority Requester: Important Projectmanager: Important Requested by: Thomas Renninger (trenn) Description: Provide a file in the kernel git which describes an installation boot entry including: - help/description - specific boot parameters - active on which arch The installation image (e.g. DVD) will then provide these specific boot entries to make it easy for: - kernel developers to add critical boot parameters required for specific HW for booting - users by providing a meaningful help at boot loader start up Currently most important settings that are coming to my mind are: - apic=bigsmp (for i386 machines with a lot cores might require that) - disable Kernel Mode Settings -> disable kernel graphics parts which won't work on all HW if set by default soon The idea originally comes from Bernhard Walle. Steffen and myself discussed that already and agreed that it makes sense to do that. On longterm it would be great to get rid of the "Failsafe" Yast boot loader functionality. This would not be necessary anymore then. This currently totally useless and outdated anyway. With the new approach, soon as one successfully booted an entry from the installation image, these boot options will be the default forever (or manually adjusted). Discussion: #1: Stefan Dirsch (sndirsch) (2009-06-22 10:09:05) I think the X' team' would like to get involved here WRT KMS. Also I believe we still want to have a possibility to detect that the user wants to start the Xserver from installation (usually fbdev driver) instead of the apparently broken native X driver. This was boot param 'x11failsafe' in the past. #2: Thomas Renninger (trenn) (2009-06-22 14:27:39) Yeah, in this case we probably need some advise from the X guys which boot params have to be passed, eventually other extra quirks are needed for KMS, no idea. But in general the responsibility and possibilty to generate/modify extra boot entries and with them passing extra kernel boot parameters and a description when to use them should rely in the kernel teams hands and thus the config file should lie in the kernel repo. Coolo, can you set this fate entry a project manager state, so that we can finally work on that at some time, thanks. #3: Stefan Dirsch (sndirsch) (2009-06-22 14:52:39) Probably the modeset option needs to be used for all relevant KMS capable DRM modules, like i915, radeon. Possibily also radeonhd (still to be implemented) and nouveau (in case it's installed, we don't ship it). So something like this: i915.modeset=0, radeon.modeset=0, radeonhd. modeset=0, nouveau.modeset=0. #5: Andreas Jaeger (a_jaeger) (2009-07-10 11:47:39) I'm a bit confused what you want to do here. What advantage will this bring us? #6: Andreas Jaeger (a_jaeger) (2009-07-14 15:13:04) (reply to #5) Just talked with Thomas: The idea is to safe the information about kernel-parameters as part of the kernel package and let the installation get this information from there - instead of hardcoding it in the installation workflow. Also the kernel would provide different options that the developers think make sense. #8: Michal Marek (michal-m) (2009-09-04 13:05:51) Adding such file(s) to git and packaging them in the binary rpms is not a problem, I think this is mainly a feature for installation images build to get the configuration from the kernels and use it when generating the menu. Steffen, what do you think? #9: Thomas Renninger (trenn) (2009-09-04 13:47:04) Yep. Steffen and I already fiddled out a config file format. It's mainly on me to add an example file to our git repo. Steffen then can implement the installation image part. I just did not found the time (and wanted to poke graphics guys about sane KMS kernel boot params to provide which should be most important for 11.2). + #10: Stefan Dirsch (sndirsch) (2009-12-12 07:14:04) + About KMS integration for openSUSE 11.3 and SLE11-SP1, please see Bug + #560438. -- openSUSE Feature: https://features.opensuse.org/306476

1 0

[openFATE 306007] Ship more vanilla
by fate_noreply＠suse.de 12 Dec '09

12 Dec '09

Feature added by: Klaas Freitag (kfreitag) Feature #306007, revision 1, last change by Title: Ship more vanilla openSUSE-11.2: Unconfirmed Priority Requester: Important openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Klaas Freitag (kfreitag) Description: Upstream projects such as KDE 4 often are developed with very high care for usability, design and eye candy, staffed with high skilled specialists and/or artists. openSUSE modifications against the vanilla versions sometimes do not really improve the upstream version. Moreover, these kind of modifications often kind of rebrand the projects, for example by replacing the KDE startmenu button by an openSUSE branded one. The openSUSE distribution as a community project should maintain the brand of the upstream projects and not hide them from the distributions users. Also patching vanilla behaviors where not technically needed or fixing problems should be handled very carefully and only happen in good dialog with upstream. -- openSUSE Feature: https://features.opensuse.org/306007

1 11

[openFATE 305686] gnome-screensaver does not respond to an expired password
by fate_noreply＠suse.de 11 Dec '09

11 Dec '09

Feature changed by: Stefan Behlert (sbehlert) Feature #305686, revision 29 - Title: [beta1] gnome-screensaver does not respond to an expired - password + Title: gnome-screensaver does not respond to an expired password openSUSE-11.2: Rejected by Stefan Behlert (sbehlert) reject date: 2009-09-08 20:39:08 reject reason: too late for that. Priority Requester: Mandatory Projectmanager: Important Requested by: Guy Lunardi (glunardi) Description: Using novell-lum-2.2.0.11-0.1 1. Authenticate to eDir, 2. Wait until the desktop is locked with screensaver enabled 3. Expire the user's password 4. Attempt to enter user password to unlock the destkop 5. The screensaver just goes into thinking mode for about 30 seconds then re-prompts the user for the password. If I disable password expire then I am able to unlock the desktop. Am attaching the gnome-screensaver file from /etc/pam.d. Relations: - gnome-screensaver does not respond to an expired password (novell/bugzilla/id: 224690) https://bugzilla.novell.com/show_bug.cgi?id=224690 Discussion: #2: Stefan Behlert (sbehlert) (2009-08-31 11:09:17) Marcus, can you give me an opinion from a security point-of-view? For me that sounds like a correct behavior. I'm wondering how other OSes handle this. #3: Marcus Meissner (msmeissn) (2009-09-07 16:32:41) (reply to #2) I think the reporter means that GNOME screensaver should show a message about the expiredness instead of "nothing". This probagly needs to be implemented in gnome-screensaver. #4: Stefan Behlert (sbehlert) (2009-09-08 20:40:02) (reply to #3) Ah, ok, I had a different understanding, but you are right, a message would be good enough. Alex, could someone from your team look at that? #5: Alex Chun Yin Lau (allau) (2009-09-17 17:29:57) Lance, why don't you take a look and see how difficult to add this message in to the screensaver. #9: Wang Lance (lzwang) (2009-11-25 12:10:27) Hi * I found that this feature is related to security. GS implemented three methods for authorization in source level. They are forking a process to call /sbin/unix2_chkpwd, directly calling pam API, and directly accessing system password database. But only one of them can be compiled in GS finally. Currently in SLED the default method is using the unix2_chkpwd helper. * I also found that the function of this feature has been implemented in the method of directly calling pam API. And it is not possible to implement the feature by avoiding modifying the source of /sbin/unix2_chkpwd which is a part of the package pam. Beause the unix2_chkpwd returns nothing about the expired password. * So I made a rpm with the method of directly calling pam API. However it need to change the default configuration about GS in /etc/pam.d. I do not kown, if it is OK. * I think maybe we need security team to look this part. * And this is the URL of new packages https://api.suse.de/build/home:lzwang:branches:SUSE:SLE-11:Update:Test/stan… Thanks Lance Wang #10: Marcus Meissner (msmeissn) (2009-11-30 10:10:25) (reply to #9) He asked me directly... quoting: The feature I am working on need to change the default pam configration of +gnome-screensaver. In /etc/pam.d/gnome-screensaver the original settings are auth include common-auth account include common-account password include common-password session include common-session and the settings I changed to are auth required pam_env.so auth optional pam_gnome_keyring.so auth required pam_unix.so sha512 shadow nullok try_first_pass use_authok account include common-account password include common-password session include common-session #11: Marcus Meissner (msmeissn) (2009-11-30 10:12:49) (reply to #10) I do not think this will work. common-auth is there for a reason, namely you can switch authentication methods. YOu are overriding it to hard and fixed new method. also with fixed password crypt method. I do not see how this can change the timeout behaviour I also do not know if gnome-screensaver is able to do that anyway due to its simple method of chceking passwords. Ludwig or Thorsten , any comment? #12: Thorsten Kukuk (kukuk) (2009-11-30 11:23:21) (reply to #10) This settings doesn't make any sense and I fail to see why this changes do fix the issue. This changes can only fix the issue of the analysis of the problem is completly wrong. Expires is only checked in acct, so why does gnome-screensaver calles accounting at all? If gnome-screensaver should not check accounting, don't call that modules. If it should check accounting, the current behavior is exactly what you want. #13: Ludwig Nussel (lnussel) (2009-11-30 12:02:10) (reply to #12) Actually gnome-screensaver does not check accounting when using unix2_chkpwd as unix2_chkpwd doesn't check accounting. This can be seen when using a local user and expiring it's shadow info. I guess the eDir server actually locks the account or the pam module that authenticates with the eDir server gets it wrong. FWIW even if gnome-screensaver is compiled without unix2_chkpwd ie does the pam conversation itself and does call pam_acct_mgmt the expiry info gets lost. gnome-screensaver doesn't check the return value of pam_acct_mgmt... #14: Thorsten Kukuk (kukuk) (2009-11-30 12:05:42) (reply to #13) Ok, then my analysis is the following: - Problem only happens with novell-lum - gnome-screensaver, unix2_chkpwd and pam_unix2 do all ignore accounting => novell-lum checks accounting in auth phase, too. This is a novell- lum bug and should be handled via bugzilla, but nothing we can change on SLE* #15: Thorsten Kukuk (kukuk) (2009-11-30 12:07:39) (reply to #14) And this explains why the modified pam config file "fixes" the issue: it removes novell-lum. Removing novell-lum from common-auth would have the same effect. #16: Wang Lance (lzwang) (2009-12-01 04:46:50) I am sorry. I lost a lot of the details about the way of modifying. 1. I know little about lum or eDir. 2. According comment 3 and 4, I just want gnome-screensaver to show a message instead of no response. 3. The return of the unix2_chkpwd is just only Yes or NO. But the return of directly calling pam includes all kinds of errors. And the errors already can be shown in the dialog according the source code. So I change the way from unix2_chkpwd to directly calling pam. 4. With the pam module compiled in, gnome-screensaver could not make successful auth as the default configuration of /etc/pam.d/gnome- screensaver needs privilege rights. So I change the default configuration. 5. I do not known if it is OK to change the default configuration, so I ask Marcus. 6. Because I konw little about eDir, so I comment the package URL hoping anyone can test it with the eDir configuration. Hope you can understand. After reading your comments I am also sure that the reason is at novell- lum. Beause checking expiration is in account management stage of pam. Anyway I think it is better use the way directly calling pam instead of unix2_chkpwd as the former can return more info than the latter. And another request if anyone could tell me that is there any message shown when the gnome-screensaver compiled with pam is under the configuration of eDir and the password is expired. Thanks, Lance Wang -- openSUSE Feature: https://features.opensuse.org/305686

1 0