January 2009 - openSUSE Features - openSUSE Mailing Lists

[openFate 300758] Show orphaned packages
by fate_noreply＠suse.de 06 Jan '09

06 Jan '09

Feature changed by: Ján Kupec <jkupec(a)novell.com> Feature #300758, revision 34 Title: Show orphaned packages openSUSE-10.2: Rejected by Thorsten Kukuk <kukuk(a)novell.com> 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. openSUSE-10.3: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2007-07-17 17:03:57 reject reason: Postponing. openSUSE-11.0: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2007-11-21 12:16:20 reject reason: Out of scope for 11.0 openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-07-07 13:34:02 reject reason: Postponing, needs underlaying infrastructure to be fixed first. openSUSE-11.2: New SLED-11 SLED-11-SP1 SLES-11 SLES-11-SP1 Requested by: Stephan Binner (beineri) Interested: Andreas Jaeger (a_jaeger) + Interested: Ján Kupec (jkupec) Interested: Matthias Eckermann (mge1512) Interested: Vincent Untz (vuntz) + Partner organization: openSUSE.org 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. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=300758

1 0

[openFate 302921] Testing openSUSE Feature Tracking
by fate_noreply＠suse.de 05 Jan '09

05 Jan '09

Feature changed by: Thomas Schmidt <tschmidt(a)novell.com> Feature #302921, revision 23 Title: Testing openSUSE Feature Tracking openSUSE-10.3: Done Requested by: Andreas Jaeger (a_jaeger) Interested: Stephan Kulow (coolo) Partner organization: openSUSE.org Description: Just a test - should go to opensuse-features(a)opensuse.org Discussion: #1: Hendrik Vogelsang (hennevogel) (2007-10-30 13:00:36) blah blah blah #2: Hendrik Vogelsang (hennevogel) (2007-10-30 13:02:35) (reply to #1) blubb lubb lbuib #13: Hendrik Vogelsang (hennevogel) (2007-10-30 13:57:04) (reply to #1) dsdsdwsd #14: Hendrik Vogelsang (hennevogel) (2007-10-30 13:59:12) (reply to #13) wsdsdsds #15: Hendrik Vogelsang (hennevogel) (2007-10-30 14:01:10) (reply to #13) dsdsds #16: Hendrik Vogelsang (hennevogel) (2007-10-30 14:11:35) (reply to #13) ddsddds #3: Hendrik Vogelsang (hennevogel) (2007-10-30 13:12:39) this is working #4: Hendrik Vogelsang (hennevogel) (2007-10-30 13:16:03) (reply to #3) or bnot #10: Hendrik Vogelsang (hennevogel) (2007-10-30 13:48:53) (reply to #3) dwsdsdsd #5: Hendrik Vogelsang (hennevogel) (2007-10-30 13:27:44) swsasaas #6: Hendrik Vogelsang (hennevogel) (2007-10-30 13:33:36) sqsqasas #7: Hendrik Vogelsang (hennevogel) (2007-10-30 13:36:11) wdwdswd #8: Hendrik Vogelsang (hennevogel) (2007-10-30 13:38:00) dwsdsds #9: Hendrik Vogelsang (hennevogel) (2007-10-30 13:46:33) wswdds #11: Michael Loeffler (sprudel24) (2007-10-30 13:49:14) wjnd sd s�dlkj sid #12: Hendrik Vogelsang (hennevogel) (2007-10-30 13:52:27) (reply to #11) sasasas #17: Hendrik Vogelsang (hennevogel) (2007-10-30 14:48:56) (reply to #12) xdsdsds #18: Gerald Pfeifer (geraldpfeifer) (2007-11-02 21:51:25) Moving from openSUSE 10.3 to openSUSE 11.0. #19: Juergen Weigert (jnweiger) (2008-07-29 21:53:03) ping-pong. + #20: Thomas Schmidt (digitaltomm) (2009-01-05 15:54:14) + test... updated keeper -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=302921

1 0

[openFate 303532] Reduce size of updates for openSUSE Factory
by fate_noreply＠suse.de 03 Jan '09

03 Jan '09

Feature changed by: Gerald Pfeifer <gp(a)novell.com> Feature #303532, revision 14 Title: Reduce size of updates for openSUSE Factory Buildservice: Evaluation Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Stephan Kulow <coolo(a)novell.com> reject date: 2008-06-06 09:06:29 reject reason: not really attached to a specific openSUSE version Priority Requester: Important Projectmanager: Important openSUSE-11.1: Rejected by Adrian Schröter <adrian(a)novell.com> reject date: 2008-11-06 16:10:03 reject reason: This is a build service feature, but no distribution feature. Priority Requester: Important Projectmanager: Important Requested by: Michael Loeffler <michl(a)novell.com> + Partner organization: openSUSE.org Description: Each update currently is around 2GB which is already much for broadband bandwith. For user with less bandwith it's by and large impossible to use Factory. Goal is to reduce size of updates and stay with frequent updates to offer latest software to the user. As we want more people using Factory it's usage needs to be conveniant. Discussion: #1: Stephan Kulow <coolo(a)novell.com> (2008-03-27 16:48:43) According to discussions with Rudi and mls, the delta setup on dist need to be changed to also contain the rpm header and the deltas need to be indexed in a way that zypp will see them. So we can still use drpmsync for internal distribution and put the deltas only in instsource for mirrors. #2: Duncan Mac-Vicar <dmacvicar(a)novell.com> (2008-04-22 13:28:56) This will happen automatically once the remaining parts of libzypp deltarpm handling are finished. We only need to agree on the format. I will propose something today. #3: Duncan Mac-Vicar <dmacvicar(a)novell.com> (2008-05-26 17:09:31) ZYpp side is done. The only thing that needs to be done is to generate the deltarpm metadata in factory. I will post link to documentation and examples shortly. + #4: Gerald Pfeifer <gp(a)novell.com> (2009-01-03 14:54:00) + Opening this up for openSUSE.org. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303532

1 0