March 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 302923] handle redirection to mirrors robustly
by fate_noreply＠suse.de 03 Mar '09

03 Mar '09

Feature changed by: Duncan Mac-Vicar (dmacvicar) Feature #302923, revision 26 Title: handle redirection to mirrors robustly openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-11-28 15:42:20 reject reason: Out of scope for 11.0 Priority Requester: Neutral openSUSE-11.1: Rejected by Matthias Eckermann (mge1512) reject date: 2008-07-22 23:04:50 reject reason: Postponing, will not be ready. Priority Requester: Neutral - openSUSE-11.2: Evaluation + openSUSE-11.2: Done Priority Requester: Neutral Requested by: Ján Kupec (jkupec) Description: The proposal is to try other mirrors from a mirror list (from the redirector?) if an error occurs on some of the mirrors while providing a file from http/ftp repository. See the references for more details. References: https://bugzilla.novell.com/show_bug.cgi?id=337410 http://lists.opensuse.org/opensuse-buildservice/2007-10/msg00170.html http://en.opensuse.org/Libzypp/Failover http://code.google.com/soc/2008/suse/appinfo.html?csaid=6F1844AB23B67E06 + http://duncan.mac-vicar.com/blog/archives/507 + http://duncan.mac-vicar.com/blog/archives/517 Discussion: #1: Stephan Kulow (coolo) (2007-11-20 11:15:49) I would be strictly against having an own mirror list. The decision was to go with the redirector (or NCC for SLE) and be done with mirrors. If that does not work, then we have to do this whole thing again, not adding untested work arounds to the product. #2: Stephan Kulow (coolo) (2007-11-20 11:16:55) so I would reject this. But it's basically "Eval by Klaas" now #3: Klaas Freitag (kfreitag) (2007-12-03 09:49:44) I agree with Coolos and Peters statements, I would also reject. #4: Klaas Freitag (kfreitag) (2008-06-12 10:06:42) I have to revert my statement that I made before in comment #3, this problem is more serious than realised in the first look. First, it should be noted that we do not control mirrors nor we do have the chance to really influence them. That means that if a mirrors decides to not longer mirror or to switch off or whatever, we have to live with it. However if a customer is sticky to a mirror that is not longer available he would not get any packages from it and thus installation or update fails. The worst thing about that is that this seems to happen regularly but we do not realise that because we're not involved. A solution would be to have a list of possible mirrors that is used by the software installation stack to find a working mirror. Peter knows much more here. But I am not sure at the moment if not Yast/zypper already has this functionality in 11.0? #5: Peter Poeml (poeml) (2008-10-01 11:58:38) YaST/zypper in 11.1 will have preliminary support for this. The essential part of http://en.opensuse.org/Libzypp/Failover has been implemented during a GSoC project this year. See http://lists.opensuse.org/zypp-devel/2008-09/msg00142.html for the status. There is a number of things left to do, like * making it the default * better debuggability - show what it does * better progress report * testing * integration into the install system so it is available during installation Further features from the proposal (mirror preference, simultaneous downloads) are not tackled yet. #6: Federico Lucifredi (flucifredi) (2009-01-07 16:29:58) I would like to see robust redirection, if possible. The details about a list, probably should not be in the feature description. #7: Todd R (theblackcat) (2009-01-22 22:20:45) Would this also be able to handle changes in the Buildservice, like renaming or moving of a certain Buildservice repository? #8: Peter Poeml (poeml) (2009-01-23 11:56:48) (reply to #7) No, that is outside the scope. Changing repositories when the system is upgraded to a next major version is also outside the scope. Maybe that can be covered by http://en.opensuse.org/Standards/Repository_Index_Service, if I am not mistaking it. #9: Duncan Mac-Vicar (dmacvicar) (2009-02-03 16:28:54) Today playing with aria (I am trying to switch the default in factory) I found out an interesting switch: --server-stat-of=file --server-stat-if=file The first one ouputs the mirror statistics of the servers used, and the second one uses its as input: cat stats host=download.opensuse.org, protocol=http, dl_speed=0, last_updated=1233674714, status=OK host=widehat.opensuse.org, protocol=http, dl_speed=8525008, last_updated=1233674714, status=OK It may make sense to make the MediaAria backend to store this in var/cache/zypp and use it as input for next time too. + #10: Duncan Mac-Vicar (dmacvicar) (2009-03-03 16:36:03) + This feature is done, see the blog posts in the references. + everything else, bugzilla. -- openSUSE Feature: https://features.opensuse.org/302923

1 0

[openFATE 300758] Show orphaned packages
by fate_noreply＠suse.de 02 Mar '09

02 Mar '09

Feature changed by: Feature crawler (fate_crawler) Feature #300758, revision 56 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 - Requested by: Stephan Binner (beineri) + 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) -- openSUSE Feature: https://features.opensuse.org/300758

1 0

[openFATE 120326] Resume download
by fate_noreply＠suse.de 02 Mar '09

02 Mar '09

Feature changed by: Pascal Bleser (pbleser) Feature #120326, revision 53 Title: Resume download openSUSE-10.2: Rejected by Stanislav Visnovsky (visnov) reject date: 2006-09-21 09:56:17 reject reason: Not enough resources to implement in time. Priority Requester: Desirable Projectmanager: Desirable openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-07-25 15:20:32 reject reason: Out of time. Postponing. Priority Requester: Desirable Projectmanager: Desirable openSUSE-11.0: Rejected by Jiri Srain (jsrain) reject date: 2008-03-28 13:51:03 reject reason: Out of resources for 11.0. Priority Requester: Desirable Projectmanager: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-01 11:34:46 reject reason: Postponing, needs downloading refactor. Priority Requester: Desirable openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Klaus Kämpf (kwk) Description: YaST/YOU times out too easy when downloading large packages like kde- base (14 MB) over a single ISDN connection. Please cache the half downloaded package so I don't have to start from the beginning again. See http://bugzilla.suse.de/show_bug.cgi?id=9740 (http://bugzilla.suse.de/show_bug.cgi?id=9740) http://bugzilla.suse.de/show_bug.cgi?id=278507 (http://bugzilla.suse.de/show_bug.cgi?id=9740) Discussion: #1: Gerald Pfeifer (geraldpfeifer) (2006-06-30 17:40:31) Klaus, do you now whether this is still an issue? #2: Klaus Kämpf (kwk) (2006-06-30 18:38:23) We still have very large packages (kernel, OpenOffice_org) which might not download completely in one go. #5: Milisav Radmanic (radmanic) (2006-09-08 15:25:57) (reply to #4) this applies to the media manager and Jiri already agreed to return this back to the YAST team, since Marius only helped out during CODE 10. Marius will of course help with the implementation, by sharing his knowledge. #7: Stanislav Visnovsky (visnov) (2007-11-23 10:32:46) Related to commit-refactoring. #9: Federico Lucifredi (flucifredi) (2008-06-12 20:21:33) Klaus, are you still running ISDN? just kidding :-) Stano, please your opinion on workload - is this easily achievable? if not, there are hgher priorities. #10: Stanislav Visnovsky (visnov) (2008-06-20 13:10:21) (reply to #9) Jiri, could we get estimate for this? #11: Jiri Srain (jsrain) (2008-08-04 08:59:34) (reply to #10) Since curl itself does support resuming download, then this feature should not be hard to be implemented. #12: Ruchir Brahmbhatt (ruchir) (2009-01-17 12:07:25) I also vote for this feature. #13: Dmitry Mittov (michael_knight) (2009-01-19 09:01:09) It is also a great problem when you use slow mirror. download.opensuse. org redirects me to one of yandex mirrors (score 20). And I have timeout on big packages. #14: Piotrek Juzwiak (benderbendingrodriguez) (2009-01-21 18:17:13) I'd vote at least for a way to change the timeout settings for YaST or it doesn't solve the problem? #15: Alam Aby Bashit (init7) (2009-01-22 09:35:17) I'd like to vote this feature implemented in 11.2. You surely want to have resume capability if you have unreliable yet slow internet connection for say, updating KDE 4.2 :) #16: Duncan Mac-Vicar (dmacvicar) (2009-01-22 15:14:44) (reply to #15) Please stop this "I vote for this" or "+1" or "mee too" comments. There is no voting system in FATE yet, but following a discussion about "I want this too" makes hard to evaluate features. #17: James Mason (bear454) (2009-01-24 06:05:01) Could this be accomplished using a bittorrent backend instead of curl ? #18: Jan Engelhardt (jengelh) (2009-01-30 15:31:33) (reply to #17) ISDN is already slow as it is. I would not want to spend more time downloading just because of the metadata traffic that is going to happen. Not to mention what happens if there are no peers around or they configured themselves to upload-limit themselves. Still, most download.opensuse.org downloads are faster than a torrent for me. + #19: Pascal Bleser (pbleser) (2009-03-02 08:42:26) + Caching is one thing. But even using retries in curl would help, see + "curl --retries". -- openSUSE Feature: https://features.opensuse.org/120326

1 0

[openFATE 302159] zypper: Add option to only download packages (-d)
by fate_noreply＠suse.de 01 Mar '09

01 Mar '09

Feature changed by: Jan Engelhardt (jengelh) Feature #302159, revision 31 Title: zypper: Add option to only download packages (-d) openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-06-19 14:19:54 reject reason: Postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-04-04 14:32:54 reject reason: Running out of time, postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-11 22:23:41 reject reason: Postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Jiri Srain (jsrain) Description: rug has a '-d' option which causes it only download packages, not to install them. zypper does not have one. to make use of such options (download packages and install them later) zypp must be able to keep the packages downloaded and use them later instead of downloading them again (eg. some kind of persistent cache). References: https://bugzilla.novell.com/show_bug.cgi?id=230704 See also feature #300747 Discussion: #2: Ján Kupec (jkupec) (2007-06-05 13:43:33) (reply to #1) First, we must have a clue how to do it :O) #5: Michael Andres (mlandres) (2007-06-18 13:21:51) (reply to #2) We need a persistent package cache, where packages are indexed by MD5, SHA. Commit has to be rewritten to separate download and install code (still offering alternating download/install or download all then install). And we need some cache cleanup policies. But we probabely don't want to do this before we know the refactored zypp runs smoothly, so I would not promise this for 10.3 #8: Federico Lucifredi (flucifredi) (2007-06-18 15:48:59) (reply to #5) As an aside, indexing will cause you probelsm with blind-revisioned packages, depending on how you implement it. #4: Duncan Mac-Vicar (dmacvicar) (2007-06-18 09:19:27) (reply to #3) This means changing the commit, and we can only do that if we are ahead of time with the other changes. #6: Jiri Srain (jsrain) (2007-06-18 14:40:08) Duncan, Michael, thanks! Stano, please, postpone for 11.0. #7: Federico Lucifredi (flucifredi) (2007-06-18 15:46:55) Lets not forget that 70%+ of OpenSUSE users have broadband according to the survey, which means this is a marginal advantage, albeit a nice one (I imagine, users who are charged by the bit, and advanced users doing who-knows-what will take advantage of the ability to retrieve packages from the cache). + #13: Jan Engelhardt (jengelh) (2009-03-01 17:02:04) (reply to #7) + Broadband is actually a pretty broad term, and so the survey item + probably did not have much value. #10: Stanislav Visnovsky (visnov) (2007-11-23 11:26:31) zypper improvements, commit re-factoring. -- openSUSE Feature: https://features.opensuse.org/302159

1 0

[openFATE 305351] pam_mount update to latest stable version
by fate_noreply＠suse.de 01 Mar '09

01 Mar '09

Feature changed by: Jan Engelhardt (jengelh) Feature #305351, revision 6 Title: pam_mount update to latest stable version openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Michael Calmer (mcalmer) Description: The author of pam_mount declared the current version 0.X as unsupported. We should update 11.2 to the newest version. We can also think about an update for SLE11 SP1 if possible. The problem here are massive changes in the configuration file again. A clean and safe convert of the configuration might not be possible. Relations: - pam_mount: update to latest (novell/bugzilla/id: 438457) https://bugzilla.novell.com/show_bug.cgi?id=438457 + Discussion: + #2: Jan Engelhardt (jengelh) (2009-03-01 16:34:42) + Anything but the latest two top releases are basically unsupported. + The config file has been stripped of most built-in defaults that nobody + ever changes anyway. For a conversion, just strip everything but < + mntoptions>, <volume> and <luserconf>. -- openSUSE Feature: https://features.opensuse.org/305351

1 0