October 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 120326] Resume download
by fate_noreply＠suse.de 27 Oct '09

27 Oct '09

Feature changed by: Christoph Thiel (cthiel1) Feature #120326, revision 91 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 + openSUSE-11.2: Rejected by (cthiel1) + reject date: 2009-10-27 15:27:57 + reject reason: Rejecting, as this will work for some cases (retry + inside the same transaction, if it is not aborted yet), but not in + general. -ENOTIMELEFT. Priority Requester: Desirable Projectmanager: 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.novell.com/show_bug.cgi?id=suse9740 (http://bugzilla.novell.com/show_bug.cgi?id=suse9740) http://bugzilla.novell.com/show_bug.cgi?id=278507 (http://bugzilla.novell.com/show_bug.cgi?id=278507) https://bugzilla.novell.com/show_bug.cgi?id=545242 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". #20: Piotrek Juzwiak (benderbendingrodriguez) (2009-04-23 16:38:17) It could be accomplished by using aria for downloading packages? There would be no more problems with timeouts and bad checksums ? #21: Ján Kupec (jkupec) (2009-04-23 17:36:18) (reply to #20) Actually we are already using aria in current development branch, so this is not so urgent anymore. Still, the download can be interrupted also in other ways than connection timeout, e.g. user decision, sudden power outage, etc... Does anyone know whether aria supports resuming? (Implementing this for the curl backend is not important anymore). #22: Markus K (kamikazow) (2009-04-25 12:49:41) (reply to #21) Yes, aria supports resuming -- even better than wget (don't know about curl), because aria uses the file size to check whether the to-be- downloaded file changed. #23: Peter Poeml (poeml) (2009-04-28 09:14:12) (reply to #21) It does. See section "Resuming Download" in its man page (http://aria2.sourceforge.net/aria2c.1.html#_resuming_download) ; and also note the -c option. #24: T. J. Brumfield (enderandrew) (2009-06-12 23:35:43) Perhaps as an addendum to this feature, I'd like to see the option to set a number of automatic retries. If Yast tells me it needs to download 3 gigs worth of packages, I don't want to watch for one package to timeout, hanging the whole process up. I'd like to configure it so that it will automatically retry the package X times, then skip the package and move on. #25: Michal Papis (mpapis) (2009-07-04 21:14:32) (reply to #24) Good thing would be here to watch network status (maybe by ping'ing the download server each few minutes, and resume download after it is back again. #30: Eduard Avetisyan (dich) (2009-09-15 09:21:41) (reply to #24) In fact, the system should keep on trying to download this particular package, and in the meantime try to download the next package in the list. I've had cases where a single package would fail to download (for unknown reason, since the same URL worked fine in firefox on the same machine), while the rest of the packages went fine. I also find 'curl' less robust and featurefull than 'wget', I wonder why the first was chosen as a backend... #28: Kahenya Kamunyu (kahenya) (2009-08-29 22:03:55) Yup, this should be there. One place Ubuntu kicks openSUSE ass #29: Vincent Petry (pvince81) (2009-09-03 07:24:15) Here in China I also experience timeouts sometimes, even over a regular ADSL connection (512 Mbps). It happens with my home connection as well as at my company's office. Resuming download would definitely be helpful, because sometimes I have to resume the same big package several times before it can finish. #31: Dave Plater (plater) (2009-10-08 13:45:48) It must be so simple to allow aria2c to use it's resume download feature, I don't understand why it hasn't been implemented yet. I've just completed a three day 2.1 gig zypper dup on a beta trial adsl line which caused many failures. The new download in advance feature would have made zypper into a super upgrade package if it wasn't blemished by libzypps inability to resume interupted downloads. I had to use aria2c manually to download two large packages directly into libzypps package cache to complete the upgrade. see https://bugzilla.novell.com/show_bug.cgi?id=545242 unfortunately the bug has been closed due to this feature request but not using aria2c's resume feature spoils an otherwise streamlined zypper -- openSUSE Feature: https://features.opensuse.org/120326

1 0

[openFATE 120340] Run download and install in parallel
by fate_noreply＠suse.de 27 Oct '09

27 Oct '09

Feature changed by: Reza Davoudi (rd1381) Feature #120340, revision 116 Title: Run download and install in parallel openSUSE-10.2: Rejected by Klaus Kämpf (kwk) reject date: 2006-08-09 11:36:10 reject reason: Not possible in 10.2 timeframe Priority Requester: Important openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-08-01 10:25:01 reject reason: Out of time. Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Jiri Srain (jsrain) reject date: 2008-03-28 13:56:11 reject reason: Out of resources for 11.0. Priority Requester: Important Projectmanager: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-11 12:06:35 reject reason: This needs to wait. Postponing. Priority Requester: Important Projectmanager: Important openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-06-03 08:43:03 reject reason: No resources for 11.2. Priority Requester: Important Projectmanager: Important openSUSE-11.3: Evaluation Priority Requester: Important Projectmanager: Important Requested by: Klaus Kämpf (kwk) Requested by: Peter Poeml (poeml) Requested by: Reinhard Max (rmax) Description: Network installation could be improved by running package download and package installation in parallel. References: https://bugzilla.novell.com/show_bug.cgi?id=60844 https://bugzilla.novell.com/show_bug.cgi?id=209799 https://bugzilla.novell.com/show_bug.cgi?id=128050 https://bugzilla.novell.com/show_bug.cgi?id=370457 https://bugzilla.novell.com/show_bug.cgi?id=370054 https://bugzilla.novell.com/show_bug.cgi?id=385711 http://en.opensuse.org/Libzypp/Failover http://metalinker.org/ Fate #300660: Download package groups before install Discussion: #2: Klaus Kämpf (kwk) (2006-08-09 11:36:42) Michael already looked at this. Should be further evaluated for 10.3 #3: Edith Parzefall (emapedl) (2007-07-31 16:56:12) Problem is: what do we do if we lost the network connection when only half the packages are installed? #7: Reinhard Max (rmax) (2008-04-10 11:42:43) (reply to #3) I think this is a general problem for network based installations. Can you elaborate if/why you see this as a special problem when download and installation are running in parallel? #8: Peter Poeml (poeml) (2008-05-19 14:49:53) (reply to #7) For reliable operation of a business critical server, it is a must that packages are downloaded first, before the installation/update is started. Otherwise a network outage can lead to a broken system which is half updated. So if parallel download/install is implemented (for desktop users, maybe...) then please make sure that it is possible to disable it. #9: Reinhard Max (rmax) (2008-05-19 16:01:15) (reply to #8) As we just sorted out on IRC, the current implementation also doesn't allow to complete download before starting installation and the feature proposed here wouldn't make this worse. But as the wish of server admins to have all packages downloaded before starting to install them is very valid, I think we should extend this feature request to contain that requirement as well, and probably rename it to "decouple download and installation". If download and installation are properly decoupled, it should just be a matter of the parameters the algorithm is called with to get one of the following behaviours: * Download and install packages one by one (as it is now) * Keep downloading subsequent packages while installing (as originally proposed here) * Use a fixed-size download cache for flow control between download an installations (in situations where download is faster than installation and disk space is limited) * Download all packages of an update or installation and install them afterwards (as requested by Peter for server admins) #10: Jiri Srain (jsrain) (2008-05-20 10:22:10) (reply to #9) We already do have similar feature: #300660: Download package groups before install #4: Edith Parzefall (emapedl) (2007-07-31 16:57:22) Please reject for 10.3. #5: Duncan Mac-Vicar (dmacvicar) (2008-01-10 16:23:46) This is included in the ZYpp plan for 11.0, however implementation will start after beta. Will keep in evaluation, it depends on other milestones for beta1 #14: Chris Hills (chaz6) (2009-02-16 16:42:06) Is there a feature request to install using both the base and updates repo so that the latest packages available at install-time are used, thus saving bandwidth? #15: Jiri Srain (jsrain) (2009-02-17 08:45:38) (reply to #14) This is how it works for quite some time. Repositories providing patches also provide the packages so that they can be installed directly from the update repositories (provided they contain newer version). #16: Duncan Mac-Vicar (dmacvicar) (2009-06-02 15:18:00) For 11.2 we will focus on flexibility of the download and install order (like installing after everything is downloaded), however parallel stuff should be done after we have this in place. Please reject. #20: Jörn Knie-von Allmen (phisiker) (2009-08-05 12:12:29) (reply to #16) Please do not reject. With a downloadprotocol this should be solvable. The Installtask can poll an that protocol (or be informed by a Signal when a download has ended. This is better then polling. Or if prefering an IPC-Framework: D-BUS. Never mind!). Such problems I had some times often to solve (but in Java) and generally, it isn't so dificult. #21: Ralph Ulrich (ulenrich) (2009-08-05 13:03:25) (reply to #20) Please reject forever: As operating system are sort of highly integrated databases there should be a commit like funcutionality: First download then install (like debian). Otherwise repositories representing a rolling release (factory) will potentially break an updating system. #22: Reinhard Max (rmax) (2009-08-06 16:18:54) (reply to #21) Yes, there are situations where this (optional) feature should better not be used, but that does not mean it should not be implemented, because there are many situations where it can be very useful. BTW, how would "download then install" give you anything near commit- like functionality? Factory could still change on the server while you are downloading and packages could still fail during installation, leaving you with an inconsistent installation. #24: Ralph Ulrich (ulenrich) (2009-08-11 23:42:59) (reply to #22) Yes, "still fail during installation": there is no commit-like functionality But in case of a changed Factory repository there would be an error: zypper dup --download-then-install || ( zypper ref && zypper dup) || ... In this more often case there would be a commit-like functionality #25: Reinhard Max (rmax) (2009-08-12 11:22:08) (reply to #24) I think the most common case is end users installing from mostly static repositories such as the original release and the official updates. That's what I had in mind when I first suggested this feature many many years ago when there was no openSUSE or Factory. So, please don't insist in this feature being rejected just because you don't have a usecase for it yourself. Nobody will force you to use it if you don't want to. #23: Reinhard Max (rmax) (2009-08-06 16:20:58) (reply to #16) As I've explained in comment #9, the different modes of operation would have been possible with a single implementation and different runtime parameters. I think this would actually be easier than implementing the different modes separately, so why hasn't it been considered? #17: Michal Papis (mpapis) (2009-07-04 20:58:23) I think great example here may be Gentoo, there You can chose the way of getting packages, by default download and installation go in paraler, but it is possible to get first sources and then run build/installation. If you are on the default and something breaks, ex. network, Yuo can always resume the last download&installation task. #18: Giuseppe Salinaro (superpeppo89) (2009-07-16 19:37:27) (reply to #17) This idea of gentoo is good... #19: Ján Kupec (jkupec) (2009-07-20 10:59:31) (reply to #18) Guys, as Duncan wrote in c#16, we are already developing the "download all, install all" mode (currently we only have "download one, install one, ..."), and yes, users will be able to choose one of these. This particular feature would be an improvement of the current mode: "download one, install one while downloading others, ...". I hope this clarifies the current status a bit. #26: Eduard Avetisyan (dich) (2009-09-15 09:16:15) (reply to #19) Sorry Jan, I think both "download one, install one, download next, install next..." and " download all, install all" are both MUCH slower than " download one, install one, download next in parallel ". Come on guys, you focused on two SLOW modes and left the only fast one for future, and that's since 5 versions! Why not reserve a couple of hundred MB (customizable) of diskspace and cache the downloads there while installing in the meantime. Hope it's not too late to think of it for os11.2... #27: Michael Kromer (mkromer) (2009-10-23 01:11:45) (reply to #26) Absolutely: I agree with you Eduard. The optimized way is to run a download process while rpm -{i,U} is running in the background, as all resources (Disk I/O, CPU, Net) can get used parallel. The only trick is to keep the installation of following packages on hold, if there is some kind of package which takes longer (like kernel-{default,source}; to keep --requires safe; example: kmp's which rely on the specific kernel version to be installed first, however even this could be developed in an optimized way, as package lists and therefore also package requirements are available at time of download). I think there would even be real great customization options possible like an option such as --download-threads. So if the installation/upgrade can keep up with the downloadspeed you will get *significant* performance. And even if not -> it could never get slower. + #28: Reza Davoudi (rd1381) (2009-10-27 14:35:07) + plz make it so that it be an option in GUI not just command line + i am sick of going through cmdline flags and options -- openSUSE Feature: https://features.opensuse.org/120340

1 0

[openFATE 305561] Install Debuginfo Package by build-id
by fate_noreply＠suse.de 27 Oct '09

27 Oct '09

Feature changed by: Alexander Orlovskyy (aorlovskyy) Feature #305561, revision 16 Title: Install Debuginfo Package by build-id openSUSE-11.2: Done Priority Requester: Mandatory Projectmanager: Important Requested by: Jan Blunck (janblunck) Developer: Jan Blunck (jblunck) Description: Since SLE11 we embed build-ids into all binaries. This build-id can be used to match the corresponding debuginfo to a binary file, a running process or a core file. To make it easy for user to install the correct debuginfo, he should be able to run the following command to get the correct debuginfo package installed: zypper install debuginfo-build-id- eb49eeaf82eff32cfbf44d94f9aa8e3cdcf0e461 Test Case: * make sure you don't have the debuginfo * run gdb * gdb will output the command line for missing debug infos, e.g. zypper install -C "debuginfo(build-id) =41d4f203d690d7db47fbcc38c3f47a2cdcc6848f" Discussion: #1: Stephan Kulow (coolo) (2009-02-17 11:17:46) Not sure why agruen is set as engmgr, this is simply some rpm hackery. Put a debuginfo.prov script in place, that checks the file list given and give it all /usr/lib/debug/.build-id files. And it will transform /usr/lib/debug/.build- id/00/d9cff1044033b4781ab47388b422b07cb72708.debug into debuginfo (d9cff1044033b4781ab47388b422b07cb72708). After that you can use zypper install -C "debuginfo (d9cff1044033b4781ab47388b422b07cb72708)" and you get kdepim4-debuginfo installed (11.1-x86_64 example). This is an effort of half an hour without testing. #2: Andreas Gruenbacher (agruen) (2009-02-17 16:15:18) (reply to #1) This should work, and the debug info repository metadata should still remain reasonably small. #3: Stephan Kulow (coolo) (2009-04-16 10:43:47) the debuginfo meta data for 11.2 and sle11 contain the build ids. Zypper support is not implemented, but I don't think it's needed as it requires a 10 line shell script wrapper that can live very well in ptools #4: Stephan Kulow (coolo) (2009-08-18 15:07:42) state in factory: gdb will output the command line for missing debug infos, e.g. zypper install -C "debuginfo(build-id) =41d4f203d690d7db47fbcc38c3f47a2cdcc6848f" #5: Alexander Orlovskyy (aorlovskyy) (2009-10-23 14:50:46) Hi Stephan , can you add an example for missing debug infos? #6: Stephan Kulow (coolo) (2009-10-23 14:59:33) (reply to #5) no, you can't use a generic example. you will have to try to debug something. gdb /bin/ls will do. It will output something like this (in 11.2): Reading symbols from /bin/ls...Missing separate debuginfo for /bin/ls Try: zypper install -C "debuginfo(build-id) =f2ec11f6e0cb0b5306e5f07fd763063747484bf6" (no debugging symbols found)...done. This zypper command should work. + #7: Alexander Orlovskyy (aorlovskyy) (2009-10-27 10:06:59) + Stephan , this feature should work with enabled debug repo in control. + xml? -- openSUSE Feature: https://features.opensuse.org/305561

1 0

[New: openFATE 308232] oci temporary repo
by fate_noreply＠suse.de 26 Oct '09

26 Oct '09

Feature added by: Jonathan Rocker (Jonathan_R) Feature #308232, revision 1 Title: oci temporary repo openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Jonathan Rocker (jonathan_r) Description: When using oci, it, ofcourse, adds the repo to YaST/zypper, but this can then lead to conflicts and complicate matters for the user. To help in this matter adding to oci an option to add the repo permanently or just for that use would help resolve this. This could lead to a repo memory of sorts. This way if a package is requested, and has been identified as having been in a repo that has been added, but is no longer there (maybe hidden and disabled type thing), then the repo could be reactivated for that package. -- openSUSE Feature: https://features.opensuse.org/308232

1 0

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

26 Oct '09

Feature changed by: Thomas Göttlicher (tgoettlicher) Feature #300758, revision 89 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: Done Priority Requester: Important Projectmanager: Important - openSUSE-11.3: New + openSUSE-11.3: Done 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. -- openSUSE Feature: https://features.opensuse.org/300758

1 0

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

26 Oct '09

Feature changed by: Thomas Göttlicher (tgoettlicher) Feature #300758, revision 87 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 Stephan Kulow (coolo) - reject date: 2009-09-08 11:07:01 - reject reason: not done, no time left + openSUSE-11.2: 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. -- openSUSE Feature: https://features.opensuse.org/300758

1 0

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

26 Oct '09

Feature changed by: Vladimirs Kuzmins (vovachaka) Feature #300758, revision 86 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 Stephan Kulow (coolo) reject date: 2009-09-08 11:07:01 reject reason: not done, no time left 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! -- openSUSE Feature: https://features.opensuse.org/300758

1 0

[openFATE 304879] OOo: Update of KDE integration to KDE4
by fate_noreply＠suse.de 26 Oct '09

26 Oct '09

Feature changed by: Vladimirs Kuzmins (vovachaka) Feature #304879, revision 104 Title: OOo: Update of KDE integration to KDE4 openSUSE-11.1: Rejected by JP Rosevear (jproseve) reject date: 2008-08-15 11:47:35 reject reason: As per PM recommendation. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.2: Done Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Stephan Binner (beineri) Description: The current OOo KDE integration (file dialogs, addressbook, interface/icon theme,...) is based on KDE3. As openSUSE 11.1/SLED 11 will likely not include KDE3 anymore it has to be upgraded to KDE4. Use Case: + dialogs - a minimum + OOo quickstarter, addressbook etc. might follow I will find this is really usefull. Discussion: #1: Stephan Kulow (coolo) (2008-06-13 09:54:23) There are far too many mandatory OOo features. Please reevaluate - it's unlikely that we won't ship KDE3 apps in SLED11 #2: Dirk Mueller (dirkmueller) (2008-06-13 13:25:48) (reply to #1) we will ship KDE3 libs, yes. that doesn't mean that we desire to have KDE3 app dependencies ;) #7: Rajesh Ganesan (ganesanrajesh) (2009-01-07 03:20:08) Well, an excellent idea and most expected too. But (http://kde.openoffice.org/) seems struck at March 2006 itself. Any plans(or chance) of revival? #8: Armin Moradi (amoradi) (2009-01-19 19:30:45) Excellent idea, again, this brings up the consistency issue with the rest of KDE4. #9: Ruurd Pels (rfpels) (2009-03-06 22:40:10) Seems to me now that we have 4.2 in FACTORY for 11.1 we can create and release an integration package there so we will be ready by the time SLES11 goes gold. #14: Michael Löffler (michl19) (2009-07-14 12:13:49) (reply to #9) Jan, can you comment on #9. As this feature is one of the highest rated ones we should start implementation better sooner than later. #15: Jan Holesovsky (kendysan) (2009-07-14 15:15:21) (reply to #14) We now have a proof of concept KDE4 integration in ooo-build, it will be a part of OOo 3.1.1. So far the theming and the file dialog were ported; also the Oxygen icons for OOo were provided - everything as a community effort. For more information please see the comments 11, 12, 13. #16: Michael Löffler (michl19) (2009-07-15 13:55:55) (reply to #15) Jan, so it looks like we can change the status of this feature into implementation, right? #17: Jan Holesovsky (kendysan) (2009-07-15 14:10:00) (reply to #16) I suppose so, so I changed the state to implementation. Let's evaluate the quality of this later in the beta phase, and reject for SP1 if the quality is poor - as I say, it is still purely community effort. #10: jimbo bigcreed (dimble_thricefoon) (2009-06-04 16:26:13) this would be nice for 11.2 #11: Karsten König (remur) (2009-06-15 15:23:55) Good news everybody! http://artax.karlin.mff.cuni.cz/~kendy/blog/archives/monthly/2009-06.html#2… (Just for tracking, most openfate users propably have seen this by now on planetsuse) #12: jimbo bigcreed (dimble_thricefoon) (2009-06-16 18:41:27) (reply to #11) dot.kde http://www.kdedevelopers.org/node/3983 KDE4 integration done by the kubuntu boys #13: Stephan Binner (beineri) (2009-07-01 20:17:03) (reply to #12) An early OpenOffice_org-kde4 package exists in Factory so this should be change to Candidate. #18: Klaus Thönnißen (thoenn_buero) (2009-08-13 14:43:29) The OOo KDE integration (mainly file dialogue) is used on SUSE Linux 10.0/ KDE3 / OOo 2.4.0.13 by more than 1.700 users in the Surveying and Land Register administration of the German Federal state Rhineland- Palatinates und must be rated as an essential aspect of user- acceptance. We actually prepare the update of our clients to openSUSE 11.1 or 11.2 with KDE 4. We would therefore strongly appreciate the OOo- KDE-integration as well as other aspects of comfort and continuity of client-usage. #19: Michael Meeks (michael_meeks) (2009-08-20 11:08:45) As Stefan says - this is now done & packaged, and I imagine will ship in the next update for SLE11, if not - then the next service pack. #20: Carlos Gonçalves (cgoncalves) (2009-08-20 13:05:01) (reply to #19) openFATE is openSUSE feature tracking, not SLE so better check first if it was done, packaged, and ready-to-be-shipped for openSUSE instead. #21: Michael Meeks (michael_meeks) (2009-08-20 12:25:46) (reply to #20) Sure - in fact this feature is used for both openSUSE and SLE. I updated the target for openSUSE - it should be fixed in 11.2. HTH. -- openSUSE Feature: https://features.opensuse.org/304879

1 0

[openFATE 307250] sax2 - ensure consistency with xrandr
by fate_noreply＠suse.de 26 Oct '09

26 Oct '09

Feature added by: Ralph Ulrich (ulenrich) Feature #307250, revision 1 Title: sax2 - ensure consistency with xrandr openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: Ralph Ulrich (ulenrich) Description: Regarding sax2 user experience: Kde4 - systemsettings has its own xrandr. LXDE has its lxrandr. Ensure users don't experience unpredictable behavior playing around with different tools or ensure there is only one such tool installable. -- openSUSE Feature: https://features.opensuse.org/307250

1 10

[openFATE 306647] Make openFATE More Readable
by fate_noreply＠suse.de 25 Oct '09

25 Oct '09

Feature added by: Karl Eichwalder (keichwa) Feature #306647, revision 1 Title: Make openFATE More Readable openFATE: Unconfirmed Priority Requester: Important Requested by: Karl Eichwalder (keichwa) Description: Please, offer an alternate style-sheets (CSS) for better readability. For me, many texts are hard to read because the contrast is rather low (light gray on white, a grayish blue on gray, this gray on that gray–all this is often hard to read). Do not take me wrong: the Web UI looks very nice, but for readability I'd rather prefer black on white. BTW, I'm wondering why the on-the-fly spellchecker is not active in the edit box? -- openSUSE Feature: https://features.opensuse.org/306647

1 3