May 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 303535] Use libnetapi to join Active Directory
by fate_noreply＠suse.de 26 May '09

26 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #303535, revision 23 Title: Use libnetapi to join Active Directory openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-07 14:56:26 reject reason: Postponing. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Mandatory + Projectmanager: Important Requested by: Ralf Haferkamp (rhafer) Description: Starting with 3.2.0 Samba will contain libnetapi, which is a C API providing features required to join an Active Directory Domain. The "Windows Domain Membership" YaST Module should switch to use this API instead of calling the "net" command. This should make the Module much easier to maintain Discussion: #9: Jiri Srain (jsrain) (2008-07-07 13:53:26) Stano, please, postpone. Minimal gain, it would requre to write a new C++ agent, and use code which has not been used before for this purpose. Let's stay with proven method and experiment with a new one for 11.2. #11: Matthias Eckermann (mge1512) (2008-07-14 20:37:06) Ralf and Samba-Team: is this reject acceptable for you - or will this have negative impact on AD integration? #12: Ralf Haferkamp (rhafer) (2008-07-28 11:51:48) (reply to #11) Jim, could you please answer Matthias' question I am not sure if libnetapi does provide anything that we need in SLED10, which is not provided by the "net" command. #13: James McDonough (jmcdough) (2008-07-29 07:22:45) (reply to #12) It is not advisable, but it is acceptable for now. Initially, it will simply mean that we are more exposed to the net command format changes, or any of the possible problems caused by running and interpreting output from external commands. Longer term, it should be done, as any new function will be implemented first through libnetapi, and not necessarily exposed through the net command. -- openSUSE Feature: https://features.opensuse.org/303535

1 0

[openFATE 305869] improve partioning UI during installation
by fate_noreply＠suse.de 26 May '09

26 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305869, revision 11 Title: improve partioning UI during installation openSUSE-11.2: Evaluation Priority Requester: Important + Projectmanager: Important Requested by: Martin Schmidkunz (mschmidkunz) Description: The partitioning dialog during installation is perceived as confusing (see Bug #461819) . The reasons for confusion are * button labeling * workflow A redesign could provide some improvement. A first idea could be: http://en.opensuse.org/Image:Partitioner_proposal_installation.png References: https://bugzilla.novell.com/show_bug.cgi?id=461819 http://en.opensuse.org/Image:Partitioner_proposal_installation.png Discussion: #1: Kevin Dupuy (kdupuy9) (2009-03-26 00:06:41) I like the proposal so far. Perhaps there could also be some improvements wrt the actual partitioning interface, similar to GParted or the Ubuntu partitioner. This way it's easier for people that need to make a small change to YaST's proposal can do it easily. GParted: http://kajar.files.wordpress.com/2009/02/gparted-gui.jpg Ubuntu: http://1.bp.blogspot.com/_MfwRx_4ERx8/Sa6_M2URLeI/AAAAAAAAAxA/rEcbk5uSrhA/s… #2: Martin Schmidkunz (mschmidkunz) (2009-03-26 16:35:44) (reply to #1) By talking about the "actual partitioning interface" do you refer to the (expert) partitioner module in YaST? (the one with the storage tree on the left pane :-)) There are some improvements planed for this interface. One of them refers to the use of the bar graph. In order to use some of the design ideas proposed by gparted we would need to extend bar graph widget at first (see FATE #303534: Extend BarGraph Widget). -- openSUSE Feature: https://features.opensuse.org/305869

1 0

[openFATE 305553] zypper: dist upgrade could error out if more than one repository exists
by fate_noreply＠suse.de 26 May '09

26 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305553, revision 11 Title: zypper: dist upgrade could error out if more than one repository exists openSUSE-11.2: Evaluation Priority Requester: Important + Projectmanager: Important Requested by: Dirk Mueller (dirkmueller) Description: I've just learned over lunch that calling "zypper dup" is wrong if you have both buildservice repositories and a distribution repository enabled. apparently one has to call it with -r name, where name points to the distribution one wants to upgrade to, and the other repositories (e.g. buildservice addons) must not be dup'ed, but only updated via update -t package. I've verified that this indeed fixes the "reinstalling/downgrading package" issues everyone seems to be complaining about. It would be nice if zypp/zypper could detect this situation and advise the user, or alternatively do the right thing automatically. I'm not sure if channels of distributions (e.g. the factory channel, or a future openSUSE 11.0 channel) can be detected in some way.. if it does, then it could automatically add the -r argument if there is only one distribution channel enabled, and altneratively error out if more than one distribution channel is in the sources list and no -r argument was given. Relations: - make zypper dup error out if more than one repository exists (novell/bugzilla/id: 385972) https://bugzilla.novell.com/show_bug.cgi?id=385972 Discussion: #1: Stephan Kulow (coolo) (2008-05-11 02:20:39) * ** Bug 388956 has been marked as a duplicate of this bug. *** #2: Duncan Mac-Vicar (dmacvicar) (2008-12-10 15:31:24) Hm. If that is so, this feature is really important :O) Just a side question: how does installation handle this (if at all)? Currently they can't, we need to add means of such identification (as well as identification of update repos). yup, sounds good #3: Lukas Ocilka (locilka) (2008-05-12 06:17:43) Installation/Upgrade has the installation repository registered as the fist one, then Add-Ons or other repositories can be added or enabled. Upgrade doesn't handle how the packages are selected to be upgraded, it just calls solver. OK, some packages are dropped by installation by default :) See bug #300540. #4: Stephan Kulow (coolo) (2008-05-12 06:25:06) the main difference: it's pretty unusual to have 13 repos during distribution update with very comparable versions. While it's not to for zypper dup. BTW: another difference: installations sets YAST_IS_RUNNING=instsys, which some packages cause not to produce errors on updates. This might be good for dup, but bad for update #5: Duncan Mac-Vicar (dmacvicar) (2008-12-10 16:56:35) Note, I moved the bugzilla entry to fate, but mls claims the bug is invalid, as it is a perfect use case to do dist upgrade with various repositories. So this feature has to be evaluated with care and gathering opinions from various sources. It may be invalid. #7: Jiri Srain (jsrain) (2008-12-11 07:58:04) (reply to #5) I don't think it is invalid; I happened to downgrade several packages from OSS repo via zypper dup :-( #8: Duncan Mac-Vicar (dmacvicar) (2008-12-11 10:10:32) (reply to #7) The solution of stop-with-error if there is more than one repository is invalid because prevent the valid usecase of dist-upgrading with more than one repo enabled (as mls pointed out). What is valid about the feature, is that multiple repo upgrade can be dangerous, and we may warn the user if there are repos for different products there. #9: Jiri Srain (jsrain) (2008-12-11 10:53:42) (reply to #8) Sorry for not being precise in my comment: of course user must be able to override this error/warning/whatever. #6: Duncan Mac-Vicar (dmacvicar) (2008-12-10 18:34:19) Idea from mls: Use the CPE ids introduced in 11.1 to issue a warning if repositories are mixed. -- openSUSE Feature: https://features.opensuse.org/305553

1 0

[openFATE 305660] more options for LDAP browser
by fate_noreply＠suse.de 26 May '09

26 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305660, revision 5 Title: more options for LDAP browser - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) + reject date: 2009-05-26 18:25:28 + reject reason: Let's not duplicate a complete ldap browser in YaST. We + need to focus our resources on more important tasks. Priority Requester: Important Requested by: Jiří Suchomel (jsuchome) Description: In YaST LDAP browser, allow: * deleting objects * renaming objects * editing opbejcClass attribute * creating new objects References: https://bugzilla.novell.com/show_bug.cgi?id=443715 + Discussion: + #1: Christoph Thiel (cthiel1) (2009-05-26 18:24:44) + Let's not duplicate a complete ldap browser in YaST. We need to focus + our resources on more important tasks. -- openSUSE Feature: https://features.opensuse.org/305660

1 0

[openFATE 305552] Support in YaST for public directories in encrypted home directories
by fate_noreply＠suse.de 26 May '09

26 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305552, revision 7 Title: Support in YaST for public directories in encrypted home directories - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) + reject date: 2009-05-26 18:28:27 + reject reason: Postponed for 11.2. Priority Requester: Important + openSUSE-11.3: Evaluation + Priority + Requester: Important Requested by: Tim Lee (timl33) Description: A follow on feature to #301923. There should be a way in the YaST users module to specify directories to make accessable in an encrypted home directory when the user is not logged in. See bug #446317. I would suggest an editable list of directories to exclude from the encrypted image, with a reasonable set of defaults. Examples of directories to exclude ~/.vacation, ~/.procmail, ~/.forward, ~/public_html and ~/.ssh References: https://bugzilla.novell.com/show_bug.cgi?id=446317 -- openSUSE Feature: https://features.opensuse.org/305552

1 0

[openFATE 304970] YaST UI for pam_mount configuration
by fate_noreply＠suse.de 26 May '09

26 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #304970, revision 10 Title: YaST UI for pam_mount configuration openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-09-12 16:48:23 reject reason: Postponing. Priority Requester: Important - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) + reject date: 2009-05-26 20:24:01 + reject reason: Out of resources for 11.2. Priority Requester: Important Requested by: Jiří Suchomel (jsuchome) Description: See bug https://bugzilla.novell.com/show_bug.cgi?id=347144: user requests a way for configuring pam_mount. We already have feature 300967 for some part, maybe other parts of it could be used in samba-client module. Michael, please check which parts might have sense Relations: - inlcude pam_mount in an up-to-date version and provide a YaST interface for it (novell/bugzilla/id: 347144) https://bugzilla.novell.com/show_bug.cgi?id=347144 Discussion: #1: Michael Calmer (mcalmer) (2008-06-30 11:25:01) Hmm, maybe we should think about a general solution. We use currently pam_mount for encrypted home directiories. Mounting samba shares is requested and now we have a general request to configure pam_mount. The pam_mount configuration is more or less the same like /etc/fstab. It provides all filesystem types which are supported via fstab and some more with special handling from pam_mount directly. The main difference is, that it is possible to have general rules which applies for all users logging-in, groups of users (supporting uid ranges, by guid or guid ranges or group names) and rules which applies only for a single user. For single user configuration a plugin for the users module would be good, but for more general rules a special module would be the best way. Such a module should have an API which can be used by other modules like samba-client to push in special rules needed fo this kind of configuration. -- openSUSE Feature: https://features.opensuse.org/304970

1 0

[openFATE 305551] Document YaST RELAX NG Schema
by fate_noreply＠suse.de 26 May '09

26 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305551, revision 6 Title: Document YaST RELAX NG Schema openSUSE-11.2: Evaluation Priority Requester: Desirable + Projectmanager: Important Requested by: Thomas Schraitle (thomas-schraitle) Partner organization: openSUSE.org Description: According to bnc#455994 (comment #17) Lukas Ocilka suggested to create a FATE entry for this purpose. Background: The YaST DTD for /etc/YaST2/firstboot.xml and the like is outdated and lead to invalid XML files. The DTD is/was rewritten as a RELAX NG Schema but elements, attributes, and attribute values are not documented yet. Business case (Partner benefit): openSUSE.org: * Documented RNG schema supports XML editors in showing tool tips during the writing of a XML file. * WIth the help of XSLT a summary can be created automatically. > reduces costs Discussion: #1: Lukas Ocilka (locilka) (2009-01-16 16:32:28) The XML format of a control file is currently documented at http://forgeftp.novell.com/yast/doc/SL11.1/tdg/inst_in_general_chap.html (generated from manually written docbook file) nevertheless this means that it has to be done at two places at once: the RELAX NG schema and its documentation itself. Having the documentation source insite the RELAX NG schema would halp to keep the documentation in sync. -- openSUSE Feature: https://features.opensuse.org/305551

1 0

[openFATE 305503] zypper: allow update by issues/bugs/advisories
by fate_noreply＠suse.de 26 May '09

26 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305503, revision 10 Title: zypper: allow update by issues/bugs/advisories openSUSE-11.2: Evaluation Priority Requester: Desirable + Projectmanager: Mandatory Requested by: Duncan Mac-Vicar (dmacvicar) Partner organization: openSUSE.org Description: Description: YUM security plugin allows to filter updates showing only ones that mention certain issues. Example: yum update --security yum update --bz 410101 yum update --cve CVE-2007-5707 --advisory RHSA-2007:1082-5 As our patches contains this metadata, we could add similar functionality to zypper. Scope The scope is only for zypper. Other front ends would require some GUI concept first. Open Issues: libzypp's PoolQuery would need support for subattributes (updateinfo. xml references are stored as subarrays) User experience * Adds command line options like the ones described above. Dependencies * libzypp Contingency Plan * Feature is new, so in a bad scenario it can simple be deactivated. Relations: - Tips and tricks: yum-security (url: http://www.redhatmagazine.com/2008/01/16/tips-and-tricks-yum-security/) Documentation Impact: New command line options would need to be documented. Test Case: The testing of this feature can be done creating a repository (for example using enhancerepo) containing patches that reference issues, like described in http://en.opensuse.org/Maintenance/Code11/Howto , and then performing updates passing to zypper command line the issues, confirming that only those issues are shown. Use Case: Sysadmin is only interested in particular updates to solve security issues or specific bug numbers or advisories. Business case (Partner benefit): openSUSE.org: Sysadmins do not update ther systems without a strict process and maximum care. Therefore it is very important to allow them to update the system to fix a single issue. It would save them the time to look that themselves package per package. Discussion: #1: Marcus Meissner (msmeissn) (2008-12-03 14:51:14) Random notes: - CVE-XXXX-YYYY RPM provides after fixing issues? - OVAL relation? #2: Duncan Mac-Vicar (dmacvicar) (2008-12-03 16:02:46) (reply to #1) About CVE provides. Right now the CVE information is in the patch (since 11.0). I don't have anything against having it as Fix(CVE-XXX-XXX) provides, but I am not sure if having them in both makes sense. Specially in the case that one issue needs more than one package, you will need to install all packages fixing the issue, and if you have 2 repos with 2 same packages providing the issue, they will conflict. #3: Duncan Mac-Vicar (dmacvicar) (2008-12-03 16:08:13) (reply to #1) I don't have knowledge how OVAL works, may be you can provide some very concrete example scenarios for the feature described above. What I can say is that the reason why the repository/product compatibility and update information in SLE11/openSUSE 11.1 is supported using CPE ( that is, product can contain a CPE id, and repos can tell to which CPE they are compatible and which CPE they update with fixes ) was to enhance our ability to do semantic queries like relate upstream security issues and installed products. OVAL uses CPE as the platform descriptor AFAIK. #4: Dirk Mueller (dirkmueller) (2008-12-04 14:58:01) adding rpm provides was also my first idea, but that has a side effect: often enough, CVE numbers are not yet known when the package is built and ends up in QA, and editing rpm provides essentially needs a rebuild, which invalidates QA. so preferably we need a way to update the rpm provides without doing a rebuild (bad) or we need a way to add it to the meta information (which is currently generated via patchinfo and where it is also too late). an idealistic approach would be to make sure that we can update this meta information after patchinfo checkin (entering the data into swamp and autobuild fetches that information when the update is released and adds it to the meta info). #5: Federico Lucifredi (flucifredi) (2009-01-07 15:52:34) This has quite a bit of customer value. BTW, there may be a duplicate out there -- openSUSE Feature: https://features.opensuse.org/305503

1 0

[openFATE 303859] simple network configuration in 1st stage
by fate_noreply＠suse.de 26 May '09

26 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #303859, revision 27 Title: simple network configuration in 1st stage openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-09 10:04:08 reject reason: Postponing, out of resources. Priority Requester: Important Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Important + Projectmanager: Important Requested by: Jiří Suchomel (jsuchome) Description: The feature of "Automatic Configuration" has a nice effect of not asking users for accepting all the default settings. However, there's (at least) one setting that is default but still not widely accepted (I think so - at least I change it always): it's the firewall that is automatically running. Wouldn't it be good to have some simple client, only opened from installation proposal upon user's request (so not by default) where could be this option configured? Even better would be "Network" part in Installation summary, with the only setting "Firewall on", which would be a link which value changes on click. References: https://bugzilla.novell.com/show_bug.cgi?id=379149 https://bugzilla.novell.com/show_bug.cgi?id=303859 Discussion: #1: Matthias Eckermann (mge1512) (2008-06-09 23:49:49) An automatically running firewall is great - for the average user. And this even applies in enterprise. I strongly recomment to reject this feature for ALL products: SLES, SLED and openSUSE, but leave it to Federico. Guy, Federico, Michl, Marcus? #2: Jiří Suchomel (jsuchome) (2008-06-10 07:49:31) (reply to #1) Well, I'm not asking for not starting firewall by default. I agree it is good to have it automatically on. But we miss an option to change this during the installation workflow. #3: Michal Svec (msvec) (2008-06-10 11:24:41) (reply to #2) Right, the proposal was to have a simple way, ideally a hyperlink, to disable the firewall, either completely or just for some services (ssh) somewhere accessible during the installation workflow. We should certainly keep the current default of running firewall automatically. #4: Lukas Ocilka (locilka) (2008-06-10 14:51:08) (reply to #3) It's quite easy to add another firewall_proposal client to the fist stage but that one could only provide enable/disable functionality (the default value is set in control file already). On the other hand, opening a firewall for some services couldn't be done as these services are known after packages with service- definitions are installed (firewall services defined by packages). Using other words: In the installed system. This feature is more about specific configuration dialogs providing functionality to Open Firewall for XYZ Service - I think only configuration of users is affected now (samba-client, SLP broadcast reply, ...?). #5: Jiří Suchomel (jsuchome) (2008-06-10 15:03:08) (reply to #4) No, it isn't. This feature is about possibility to either shut down the firewall or open ports for defined (not arbitrary) services (e.g. ssh). No samba, no SLP. It is called simple network configuration in 1st stage. #6: Lukas Ocilka (locilka) (2008-06-10 16:42:14) (reply to #5) Yes I know what is it called, but as I've already written, in first stage, firewall can be only enabled or disabled. No additional servics could be open as they are unknown in that stage. I'm just talking about the limits of the proposed firewall/network client in first stage. The rest is left on particular modules to open ports/services as required by a specific service used in second stage. Services are defined in packages, their ports, names, description. Even SSH has its own definition in openssh package: /etc/sysconfig/SuSEfirewall2.d/services/sshd . This package needen't be installed at all. #7: Jiří Suchomel (jsuchome) (2008-06-11 08:07:35) (reply to #6) And again, I am not requesting any configuration of services in this stage. Basically I want the same thing we have in current network proposal (at the beginning of currently-usually-unused 2nd stage) , where you can shut firewall down and/or open ssh port. If sshd is the problem (but in the time of installation proposal, we know if it is going to be installed or not, so it may be hidden if sshd is not selected for installation) it doesn't have to be there, and it may consist of simple firewall off/on hyperlink. So yes, it is true that firewall_proposal client ...could only provide enable/disable functionality , but this is actually the point of this feature. I should probably also make clear that I'm not requesting any additonal step in the sequence, only the option to be selected from installation summary, just like Installation from Images is enabled (disable) one. #8: Guy Lunardi (glunardi) (2008-06-12 17:34:47) (reply to #7) Could this be served by providing an hyperlink which would open the current network module presented during the normal installation? Like I had made my initial priority, I am pretty neutral on this. I think power users would appreciate the feature but most of our 1-time installation users would not care. I am fine having it if the investment is very small. #11: Jiří Suchomel (jsuchome) (2008-06-13 07:48:43) (reply to #8) Hyperlink yes, but for enabling/disabling, not for full firewall configuration. This is not really possible in 1st stage, see Lukas' comments 4 and 6. #9: Federico Lucifredi (flucifredi) (2008-06-12 18:11:07) Guys, I am not following... why do we want the enable/disable choice in 1st stage? Looks just fine to me as is. Please clarify what's the advantage of allowing the choice earlier. #10: Jiří Suchomel (jsuchome) (2008-06-13 07:47:11) (reply to #9) In previous versions, we had the network configuration proposed which user had to accept, but now the networking is (by default) configured automatically (and this is without debates fine for most users). The old screen with the network configuration had an option disable firewall with one click and this is the thing which I miss now (yes, it is possible to use the old way also in 11.0, but it brings bunch of other configuration options that are correctly done automatically). So, earlier actually means during installation . Of course this is possible to configure after the installation, but just like many other users, I'd like to have the system configured after the system is installed. #12: Federico Lucifredi (flucifredi) (2008-06-13 17:02:08) (reply to #10) okay - I understand. Yes, this is handy, as it saves the need to go through all the config when all one wants to do is remove the fw. _if_ there is a way to include in the early workflow, lets do it. Of course, that may not be the case on "keeping it simple" grounds. #13: Stanislav Visnovsky (visnov) (2008-06-19 13:21:59) (reply to #12) I agree, if we are able to find a reasonable place, would be nice to have. -- openSUSE Feature: https://features.opensuse.org/303859

1 0

[openFATE 300758] Show orphaned packages
by fate_noreply＠suse.de 26 May '09

26 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #300758, revision 66 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: Evaluation Priority Requester: Important + Projectmanager: Important 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. -- openSUSE Feature: https://features.opensuse.org/300758

1 0