October 2010 - openSUSE Features - openSUSE Mailing Lists

[openFATE 308626] Snapshot/Rollback interface to the ZYpp stack
by fate_noreply＠suse.de 21 Oct '10

21 Oct '10

Feature changed by: Duncan Mac-Vicar (dmacvicar) Feature #308626, revision 22 Title: Snapshot/Rollback interface to the ZYpp stack openSUSE-11.3: Evaluation Priority Requester: Mandatory openSUSE-11.4: Evaluation Priority Requester: Important + Info Provider: (Novell) + Info Provider: (Novell) + Info Provider: (Novell) Requested by: Duncan Mac-Vicar (dmacvicar) Developer: (Novell) Developer: (Novell) Partner organization: openSUSE.org Description: Ability for libzypp and exposed via zypper to snapshot either automatically or explicitly the system before commit happens, plus an interface to revert the system. The interface should be generic and allow for different possible implementations which should be offered depending on the context: * btrfs based if /root is btrfs * simple based on package list before commit, plus package history and current package list to determine diff last transaction * two root partitions, where the interface would clone root filesystem before commit and switch them at rollback time. The feature includes the concept, and a working implementation with one or more of the strategies described before. References: https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs http://dev.chromium.org/chromium-os/chromiumos-design-docs/filesystem-autou… http://wiki.rpath.com/wiki/Conary:conary_rollback + Relations: + - grub1 patch for btrfs boot (url: ) Documentation Impact: Requires description of the functionality in zypper options Test Case: zypper install foo bar zypper rollback System should be as before the installation. Corner cases are not important. Use Case: Administrator installs a bunch of updates, which leaves the system in an an unworkable state. He types zypper rollback to undo the changes. Business case (Partner benefit): openSUSE.org: * Customer asked about snapshoting during our last meeting. * Feature parity with Solaris which is implementing package rollback based on ZFS * RHEL goes the same route, announced btrfs rollbacks in yum * We can do better, offering something more flexible and not btrfs dependent to support different scenarios: SLES (btrfs), Appliances (dual system partition), openSUSE (simple package list) Discussion: #1: Federico Lucifredi (flucifredi) (2010-03-05 07:29:41) PM: Important for 11.3. (sorry, on web client). #3: Joachim Werner (joachimwerner) (2010-04-28 18:10:50) I have SLEPOS-specific use cases for this feature, too. IBM implemented a similar rollback feature in IRES2, based on tripwire AFAIK. Some techical considerations we need to understand: Rolling back the right things What customers really want is not a dumb rollback of everything on the system to the old state, but just the changes done by the update. So it may be necessary to make sure the snapshot only applies to the configuration directories (usually /etc) and the code directories (/usr) affected by the update, but not things like logfiles (which should be continuous) or application data (nobody wants to get their database files rolled back by accident, or data a user has saved in /home/username in the meantime). Another potential issue with some applications is that they can be in an inconsistent state if they aren't stopped during a snapshot. This is a more generic problem with snapshots as such. For this Windows has mechanisms to inform an application that it's going to do a shadow copy now. In Linux there is no single interface to trigger that, although some databases and other applications have there own way of switching into a read-only snapshotting-safe mode. So, this is all doable, but just applying a system-wide snapshot seems to be too simple. Maybe we can just copy what Red Hat is doing here (if it's good enough). Red Hat has finished this feature in Fedora, and it's probably going to be in RHEL6 at some point, too. https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs (https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs) contains a few considerations on this. Avoiding situations that can't be recovered zypper rollback sounds like a good plan at first, but it is not in all cases. If you apply an update that breaks the system, this could mean that a kernel update went wrong and you can't even boot beyond a certain stage. So there needs to be a way of entering the recovery from the earliest possible level, the boot prompt. There needs to be an option to boot into the snapshotted system, and from there eliminate the changes made after the snapshot and declare the snapshot to be the current state. For the worst case (a broken grub package or so kills the bootloader configuration) we need to have a recovery workflow (from CD or so) that can still bring back the old working state. Do one thing right, not three things that solve the same problem If we decide to go down the btrfs route (which I like) we should not also solve the same problem using several other approaches. Why use dual system partitions if you can have snapshots? + #7: Duncan Mac-Vicar (dmacvicar) (2010-10-21 10:43:26) + I would like to clarify some issues: + For rollbacks, it would be the ideal situation to have the root + filesystem completely under btrfs, otherwise you run into the problem + that kernels are not affected by the rollback and this increases + complexity. + * a) For this we need to boot with btrfs. Matthias told me we should + ignore this problem because under EFI you have to put the kernel under + /efi in a FAT partition, but my own research tells me that what is in + FAT /efi is the grub EFI program, and therefore the kernel could be in + btrfs if the grub EFI program supports finding the kernel with btrfs. + Can anyone confirm this? + * b) For booting with btrfs we need either grub2, or syslinux or a + patch for grub1 (added as a reference to the feature). Which route will + we follow here? Do we have anyone empowered to make this decision soon? + * c) if b) is solved with grub1 patch I suggest we open a feature entry + to track that one. -- openSUSE Feature: https://features.opensuse.org/308626

1 0

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

19 Oct '10

Feature changed by: Ján Kupec (jkupec) Feature #120340, revision 162 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: Rejected by (a_jaeger) + openSUSE-11.3: Rejected by Andreas Jaeger (a_jaeger) reject reason: not done Priority Requester: Important Projectmanager: Important openSUSE-11.4: New Priority Requester: Important Requested by: Klaus Kämpf (kwk) Requested by: Peter Poeml (poeml) Requested by: Reinhard Max (rmax) Developer: (Novell) 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 + https://bugzilla.novell.com/show_bug.cgi?id=638191 http://en.opensuse.org/Libzypp/Failover http://metalinker.org/ Fate #300660: Download package groups before install Related Fate #307862: Download multiple packgaes in parallel Use Case: This week i makred a upgrade of Qt libs and other things (install texlive). Yast update qt core and start the download of texlive (~250 MB) Well... the qt-x11 not be upgraded, when i can't start a qt app during the install of texlive because the qt is broken. I use kde and almost all of my applications is qt based. 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 #42: Martin Seidler (pistazienfresser) (2010-06-09 20:35:25) (reply to #9) That surgestion of Reinhard Max sound's good. And I would surgest the last (and maybe most stable) variant or at least the situation now as default. How much time could be saved in parallel installation and how much time could be wasted with a system with packages that do not fit together if the download had been broken up during installation of the fist packages? #46: Artur Mustafin (hack2root) (2010-08-26 07:21:27) (reply to #3) I think all installation technology shuld be revised: - We should invent globaly visible versioned library store, new packaging system, e.t.c. - I think it is must be a simple commit, like this: - -begin transaction -installs missing libraries/apps in libary store (multiversional, global, cached) -commit transaction - in case of any error: - -rollback trasaction - #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. #31: Bart Otten (bartotten) (2009-11-08 13:46:41) (reply to #26) Guess it is too late for for 11.2 but I think Eduard and Michael made a good point. This request is old, even before openFATE was for public... #32: Ján Kupec (jkupec) (2009-11-09 11:25:45) (reply to #26) Well, whether we should do one thing first and then the other, that's debatable, but the point is we do want this downloading while installing . The only issue here are the resources and priorities. Now that we have the first, we can hopefully move on to the next for 11.3 #37: Robert Davies (robopensuse) (2009-12-18 15:19:01) (reply to #32) #306966: [Beta2] No Shutdown/Suspend During Package Update https://features.opensuse.org/306966 is proposing making the slow disk Hog option DownloadInAdvance the default claiming practical integrity benefits, so this most popular feature request is needed to be implemented for 11.3 to mitigate end-user annoyance. #38: Duncan Mac-Vicar (dmacvicar) (2009-12-18 16:03:54) (reply to #37) Yeah, like if disk space would be a big problem nowadays compared with battery duration #39: Robert Davies (robopensuse) (2009-12-18 16:40:21) (reply to #38) Some people have netbooks with relatively limited space, SSD's are likely to become more popular to. So it is not just older machines with smaller disks. Improving battery life by reducing the time the disk needs to be spun up rather than idle, is just another reason to offer parallel download/install option. #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 #29: John Bester (johnbester) (2009-10-29 07:13:05) I think the proposed sulotion will help, but to me this is not the real important issue. The most frustrating issue around installing a small package using YaST is the repository upgrade that must complete before you can do anything. (Unfortunately we do not all have the internet speeds as are the norm in Europe and US). The worst is actually when you have your laptop somewhere where you do not have internet access and have to wait for connection timeouts before you can do an installation. It happened a few times that I just wanted to install a small tool which slipped my mind when I did a clean install (such as midnight commander) quickly so that I can continue with what I am doing. At this point I am not fussed about having the absolute latest security fix - I just need to get going. In any case, I would propose that when you open the package manager, it should kick off a thread to download repository updates into a temp folder. The next time you start the package manader, it can simply replace those repositories for which there are updates available in the temp folder. My reasoning is: If I opened the package manager yesterday and I open it again today (and maybe again later today), why should I always wait a few minutes before I can start selecting packages? Switching off the refresh feature in "Software repostories" is not an option, because it takes too long and you typically do not want it switched off. #30: Reinhard Max (rmax) (2009-10-29 09:59:10) (reply to #29) Please open a new feature request for your proposal, as it is unrelated to the feature that is being discussed here. #33: Fco. Javier Nacher (xiscoj) (2009-12-07 09:39:04) hi, why don't we learn from another package managers?. I usually use smart ( http://labix.org/smart (http://labix.org/smart) ), I think it working mode is the apropiate. It downloads in parallel and after downloading all packages, installs them sequentially, also allows to update channels pressing a button only on demand, so it opens faster. I think that parallel install is not a good choice but parallel download is more than recommended. #34: Duncan Mac-Vicar (dmacvicar) (2009-12-07 11:01:03) (reply to #33) You missunderstood the feature. The feature talks about downloading multiple files at the same time, and installing what is possible to install at the same time. It does not implies that multiple packages are installed in parallel (however it does not discard it). You give no reason when stating that "parallel install is not a good choice". Downloading in parallel is something we will do anyways. However, as we have DownloadInAdvance and DownloadInHeaps, we can download group of packages that form a minimal dependency transaction. I doubt smart has this information. This would allow us to download the maximum amount of packages (either sequential or in paralell) that can be downloaded and installed while leaving the system in a consistent state. Those could be installed in parallel while the next "heap" or group is downloaded. Any error in the next download would leave the system still in a consistent state. So yes, we should learn from smart, yum and others, but we should not just copy, as we don't have all the limitations they do have, and that means we can actually try to improve things. #35: Robert Davies (robopensuse) (2009-12-07 21:21:45) (reply to #34) It is possible to grab the small "odds & sods" together that start being downloaded early in install even if they are logically independant? The trouble I notice on network install, is that there's many small packages not particularly important packages, which don't let the TCP/IP download get to decent speed, making things crawl early on at nowhere near usual bandwidth. So a strategy, like a browser of getting small files in parrallel, whilst mainly wanting those large consistent sets you mention, might make things look pleasingly snappy, rather than naive. Of course if a large package were to be downloaded, as the small ones arrive and are installed noone would complain. #40: Fco. Javier Nacher (xiscoj) (2010-01-28 09:15:41) (reply to #34) hi, I think parallel download good be a good start point, so once you have all the packages you can install without dependency problems and you'll be sure that the system will be consistent. Of course if some packages are not dependant on others could be installed while downloading the rest. But I think this could be more difficult to implement so as first step for this features could be parallel download of packages and the next step parallel install, and maybe the first step would be easier and faster to implement for 11.3 and the second step can be delayed for next opensuse version. Improving is always good :) #36: Robert Davies (robopensuse) (2009-12-10 16:21:39) Testing out Kubuntu 9.10, and one of early things it does on starting Konqi, is suggest installing "restricted" multia-media codecs. The downloads were fast, stating off at full 10Mb/s, just tailing off a touch after a while. Similarly installing 110 bug fix updates took only a few minutes, despite requiring full kernel download. By comparison, though zypper itself is fast searching in DB, getting the repo info and sequence of small files, can really keep the end user waiting with alot of under-utilised bandwidth. #41: Thiago Sayao (sayao) (2010-06-03 03:29:13) https://bugzilla.novell.com/show_bug.cgi?id=609276 (https://bugzilla.novell.com/show_bug.cgi?id=609276) Anyone would pick this on Hack Week? I think parallel downloads would speed up things a lot. I could keep downloading when installing so the connection would not close - this would save a lot of "hand-shaking" time. #43: Emmanuel ESCARABAJAL (eescar) (2010-06-29 03:28:38) I've been using SuSE for years, since the 5.x, and been wondering since then why they stop downloading packages while installing the one just finished, as compared to some other distros who keeps downloading while installing what was ready to! Ok, I must admit that in those early days, DSL was just born and 56k connections makes each and every second of time saved quite valuable; is it a reason, now we (quite) all have fat Dsl connections, to tolerate such a waste??? I, personnaly only have a 1k dsl line and it makes a great difference with the 10k line I have at work when speaking of the net install experience ... So Please, make the download process in-interupted Soooooon! - #44: nick skeen (ns89) (2010-08-01 17:47:22) This is fine with me, as long as there's some form of limiting the number of downloads at once, and perhaps some sort of scheduler to decide which ones to download at the same time. #45: Ralph Ulrich (ulenrich) (2010-08-01 22:24:02) To prevent having a half way update done when crashing, if you use openSUSE factory then edit /etc/zypp/zypp.conf commit.downloadMode = DownloadInAdvance - - #47: Wallacy Freitas (wallacyf) (2010-09-06 18:52:33) I know the installation order of packages is important. But that does not mean having to wait to install a package for now start downloading the next. Downloading and installation are separate tasks. Package "A" was downloaded, the package "A" goes to "queue" for installation, while this package "B" is downloaded, then "C" then "D", etc.. Just use the term "cache", the packets are downloaded regardless of the previous packet has already been installed. So you can even download multiple packages at once. It would also be possible to install more than one at the same time, if in compliance with the dependences of course. The biggest problem of downloading one by one, is time spent with HTTP requests only to start the download itself. Outside we have to expect a package to be installed to start the next request. #48: Jeremy Thornton (leebrad) (2010-09-16 23:19:45) Would it be possible to have a switch option depending on the usage. Simply, by default, especially for the desktop use 1. Download, 2. Que for Install (Install), 3. Begin downloading next file. Call it REAL- TIME mode. Then offer an alternative called BATCH mode which simply downloads all files needed and installs when the entire download is complete, and the downloaded files are kept in cache until all are verified download and installed. This option allows an administrator to choose based on the particular setting of the unit. It could look something like zypper -rt install whatever (REAL-TIME mode) zypper -batch install whatever (BATCH mode) and in the YAST have GUI option to choose at the top before downloading. -- openSUSE Feature: https://features.opensuse.org/120340

1 0

[New: openFATE 310721] Pkg-Config with Packagekit/Zypper integration
by fate_noreply＠suse.de 18 Oct '10

18 Oct '10

Feature added by: Sławomir Lach (Lachu) Feature #310721, revision 1 Title: Pkg-Config with Packagekit/Zypper integration openSUSE-11.4: Unconfirmed Priority Requester: Important Requested by: Sławomir Lach (lachu) Description: This idea is made to make installing from source easiest as possible. Many tools to generating makefile (configure) uses pkg-config a lot. Pkg-config returns complirer flags and path to include files. When the package devel/header files isn't insralled, pkg-config only returns error code. We should modify pkg-config to search devel packages in the repository(like cnf). We can integrated zypper, but integrating PackageKit instead is also a good choice. The behaviour can be simply: displaying package name to install on error out. Not always package name are matched to name suggested by configuration script. I can also imagine to write complete replacement for make, which modify system path to directory with special wrapper for compilers/pkg-config. Use Case: Marthin liketto install some software into newest version onto home directory. He can use console, but won't waste a time for searching packages. -- openSUSE Feature: https://features.opensuse.org/310721

1 0

[openFATE 120326] Resume download
by fate_noreply＠suse.de 15 Oct '10

15 Oct '10

Feature changed by: damian ivanov (damianator) Feature #120326, revision 96 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: Rejected by (cthiel1) + openSUSE-11.2: Rejected by Christoph Thiel (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 #32: Glenn Doig (doiggl) (2010-01-16 12:39:46) I see aria2c does have a continue feature. aria2c --help option shows the following -c, --continue Continue downloading a partially downloaded file. Use this option to resume a download started by a web browser or another program which downloads files sequentially from the beginning. Currently this option is only applicable to http(s)/ftp downloads. Possible Values: true,false. Default: false. Tags: basic,ftp,http -- openSUSE Feature: https://features.opensuse.org/120326

1 0

[openFATE 300758] Show unneeded packages
by fate_noreply＠suse.de 15 Oct '10

15 Oct '10

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

1 0

[New: openFATE 309096] Wacom tablets
by fate_noreply＠suse.de 15 Oct '10

15 Oct '10

Feature added by: Bojan IVANCIC (bivancic) Feature #309096, revision 1 Title: Wacom tablets Package Wishlist: Unconfirmed Priority Requester: Important Requested by: Bojan IVANCIC (bivancic) Description: To install and use of Wacom tablets is not a user friendly task. Intuos 4 is not supported but should be long ago. -- openSUSE Feature: https://features.opensuse.org/309096

1 1

[New: openFATE 310472] Make automatic installation of gstreamer codecs work
by fate_noreply＠suse.de 13 Oct '10

13 Oct '10

Feature added by: Vincent Untz (vuntz) Feature #310472, revision 1 Title: Make automatic installation of gstreamer codecs work openSUSE-11.4: Unconfirmed Priority Requester: Important Requested by: Vincent Untz (vuntz) Description: PackageKit has some magic to install codecs when needed. However, this requires some Provides in the rpm containing the codecs. We need to add a script that will create those provides and change rpm to call that script if it exists. -- openSUSE Feature: https://features.opensuse.org/310472

1 5

[openFATE 306408] blah
by fate_noreply＠suse.de 12 Oct '10

12 Oct '10

Feature changed by: Thomas Schmidt (digitaltomm) Feature #306408, revision 10 Title: blah openFATE: Rejected by Hendrik Vogelsang (hennevogel) reject date: 2009-05-07 16:53:14 reject reason: done testing Priority Requester: Important Info Provider: (Novell) Info Provider: Heidi Lahtinen (chrysantine) Requested by: Hendrik Vogelsang (hennevogel) Description: This is a test feature. Discussion: #1: Hendrik Vogelsang (hennevogel) (2009-05-07 16:09:14) please make a comment #2: Hendrik Vogelsang (hennevogel) (2009-05-07 16:19:52) this is a comment #3: Hendrik Vogelsang (hennevogel) (2009-05-07 16:34:47) (reply to #2) why? #4: Hendrik Vogelsang (hennevogel) (2009-05-07 16:45:19) (reply to #3) hrrrmmmm #5: Michael Löffler (michl19) (2009-05-11 16:03:02) Henne, there is something important missing. + #6: Thomas Schmidt (digitaltomm) (2010-10-12 13:21:26) (reply to #5) + test -- openSUSE Feature: https://features.opensuse.org/306408

1 0

[New: openFATE 310689] Remember network settings while rebooting into installed system
by fate_noreply＠suse.de 08 Oct '10

08 Oct '10

Feature added by: matthias propst (l1zard) Feature #310689, revision 1 Title: Remember network settings while rebooting into installed system openSUSE-11.4: Unconfirmed Priority Requester: Important Requested by: matthias propst (l1zard) Description: I installed openSUSE 11.3 via netinstall. Because I'm on a Netbook I used my wireless lan connection. And because I also didn't want switching between my netbook and my desktop system I activated VNC for the installation procedure. That just ran all fine but after the restart during the installation (when booting into the installed system) the configuration settings for my network connection are gone and therefore I had to configure it manually in a terminal. It would be nice if we could extend the installer so it does remember these settings. -- openSUSE Feature: https://features.opensuse.org/310689

1 0

[New: openFATE 309167] lzma compression for primary.xml
by fate_noreply＠suse.de 08 Oct '10

08 Oct '10

Feature added by: Michal Marek (michal-m) Feature #309167, revision 1 Title: lzma compression for primary.xml Buildservice: New Priority Requester: Mandatory openSUSE-11.3: New Priority Requester: Mandatory Requested by: Michal Marek (michal-m) Description: Providing all exported kernel symbols as individual dependencies (fate 305945) resulted in a DoS against download.o.o, because the primary.xml.gz file in the update repository grows with each kernel update (bnc 582907 and 586960). The least intrusive fix to this seems to be: Sort the entries in primary.xml and provide a lzma compressed version in addition to primary.xml.gz. Testing shows that this brings the metadata growth back to the 11.1 symset approach (about 100k for each subsequent kernel update) and also reduces the size, so it would be beneficial also for normal repositories. The repomd.xml format extension could look like: <data type="primary"> <location href="repodata/primary.xml.gz"/> <checksum type="sha">1233456...</checksum> <timestamp>1268305225</timestamp> <open-checksum type="sha">abcdef...</open-checksum> </data> <data type="primary-lzma"> <location href="repodata/primary.xml.lzma"/> <checksum type="sha">56789a...</checksum> <timestamp>1268305245</timestamp> <open-checksum type="sha">abcdef...</open-checksum> </data> With the meaning that if there is a primary.xml.lzma with the same open-checksum, download this one instead of primary.xml.gz, decompress it with lzma (in default install since 11.1) and then continue as usual. Old clients would continue working with the primary.xml.gz file. The feature primarily targets libzypp, but also extending yum should not be hard. Relations: - Get rid of "symsets" in kernel package dependencies (feature/id: 305945) - zsync support for update channel refresh (feature/id: 309088) - fate #305945 causes extreme update channel metadata overhead (novell/bugzilla/id: 586960) https://bugzilla.novell.com/show_bug.cgi?id=586960 -- openSUSE Feature: https://features.opensuse.org/309167

1 4