March 2013 - openSUSE Features - openSUSE Mailing Lists

[openFATE 120115] Common Virtual File System Support
by fate_noreply＠suse.de 12 Mar '13

12 Mar '13

Feature changed by: Joachim Werner (joachimwerner) Feature #120115, revision 45 Title: Common Virtual File System Support openSUSE-11.1: Rejected by JP Rosevear (jproseve) reject date: 2008-07-21 13:06:16 reject reason: Lack of time before feature freeze. Priority Requester: Important Projectmanager: Important openSUSE-11.2: Rejected by JP Rosevear (jproseve) reject date: 2009-08-21 08:47:14 reject reason: Past feature freeze deadline Priority Requester: Important - openSUSE-11.3: Rejected by (a_jaeger) + openSUSE-11.3: Rejected by Andreas Jaeger (a_jaeger) reject date: 2010-03-15 13:07:55 reject reason: This would be nice indeed but I'm not seeing this happen at the moment. Priority Requester: Important Requested by: Joachim Werner (joachimwerner) Engineering Manager: JP Rosevear (jproseve) Partner organization: openSUSE.org Description: KDE and Gnome both use their own virtual file system layer to access protocols like SSH, WebDAV, FTP, or SMB (KIO slaves vs. gnome-vfs). This functionality should be available from all major desktop applications on both desktops. Different approaches could be taken: * Implement a lower-level VFS layer that can be used from all applications. This approach has obvious limits because all remote file systems would have to be "mounted" locally, which is not as flexible as accessing them via URLs. * Separate file loading and file storage from the application cores and use the desktop environments' native file dialogs. This approach has worked quite well for some applications (e.g. OpenOffice.org, Sodipodi), but may be a painsome process for others. * Use the useful parts from the non-KDE/non-Gnome applications and write new, native applications using those parts. This has been done with the Gecko rendering engine. Another example is gphoto2, which used to be a GTK application, but now is a library that is used in Gnome and KDE digital camera management frontends. How could we reach that goal? * KDE and Gnome developers at Novell should cooperate to develop a guideline for 3rd party developers. * Where possible, tools should be provided to help developers with using the native dialogs. Discussion: #1: Joachim Werner (joachimwerner) (2006-02-14 15:30:07) FUSE and user space filesystems like fusesmb or fuse_kio can deliver this. We need to put some effort into this post Code 10. #2: Stefan Behlert (sbehlert) (2008-05-21 21:15:25) Michael, you did some evaluation wrt. KDE/GNOME using common stuff. Anything helpful to add? #3: Gary Ekker (gekker) (2008-05-29 14:35:45) Given Novell and the communities recent investement in gvfs and the fact that KDE4 isn't using gvfs, I'm going to reject this one. #4: Michael Meeks (michael_meeks) (2008-06-03 11:14:21) Sure - this is a great direction to go in. Wrt. the different approaches - I want to use this as an opportunity to share code & reduce bug fixing / sustain costs: and of course to unify the ISV platform. I'm not that enthusiastic about FUSE from this angle: I would prefer a single implementation that can be compatibly wrapped by both existing KIO and GIO APIs. In addition, I believe we need to unify the wallet / keyring pieces since network IO slaves are fairly useless without that. #5: Joachim Werner (joachimwerner) (2008-06-06 11:37:22) I'm not quite sure I understand why this request is closed for 11. The problem persists, and AFAICS my initial description is still valid, regardless of the technology switch to gvfs on the GNOME side. In addition to that gvfs does not address the problem of making files available transparently to non-GNOME or even non-GUI apps (think vi), or does it? Please either reject it for time reasons and move it to a later version or even better address it for 11, but we should not close and forget about it, as the pain is still there for any user of a desktop that runs at least one major application from the "other side" or from the pre-GUI times. #6: Michael Meeks (michael_meeks) (2008-06-06 12:43:31) (reply to #5) Sure - I want to see this in sled11 too, and we have a plan to investigate this: lets not close it now. #7: Gary Ekker (gekker) (2008-06-09 08:37:43) (reply to #5) GVFS does make files available. At least you can tab-complete a path on a remote host when entering the path for scp for example. #8: Michael Meeks (michael_meeks) (2008-06-09 16:40:05) (reply to #7) Gary: the advantage of switching to a common IO subsystem is that it would make both KDE & Gnome equal peers in terms of their device access: it would also reduce our costs wrt. long term maintainance, and make things far easier for ISVs to integrate with both desktops in one shot. The fact that GVFS works, or KIO works in a given place is not that relevant here :-) #9: Norbert Frese (nf2) (2009-06-01 02:10:36) Just to mention it: Here is some experimental work, which tries to address this problem: http://live.gnome.org/KioGioBridge It's not that hard to run KIO on top of GIO/GVFS - but to make it neat, the dependencies of GVFS need to be approached as well. Particularly gconf and gnome-keyring. The latter could perhaps be tackled by making the KDE password manager GUI "dualistic" (allow to peek into both password managers - KWallet and Keyring daemon). #10: Will Stephenson (wstephenson) (2009-08-24 13:45:21) I agree that this will be nice to have but it's out of scope for an SP. By replacing a core part of the platform with an experimental compatibility layer we would be replacing reliable and painstakingly maintained upstream code with something new that will run into every API corner case and badly specified behaviour, something we have to maintain ourselves, and which has not had any testing in openSUSE. IMO if we do this, we should do it right, upstream by proposing a common standard and taking it when it has matured there. KWallet is being ported to a standardised gnome-keyring backend so this will be easier in future. -- openSUSE Feature: https://features.opensuse.org/120115

1 0

[New: openFATE 314904] Installer: remove the requirement of mount points to be on unencrypted device
by fate_noreply＠suse.de 12 Mar '13

12 Mar '13

Feature added by: Denys Rtveliashvili (rtvd) Feature #314904, revision 1 Title: Installer: remove the requirement of mount points to be on unencrypted device openSUSE Distribution: Unconfirmed Priority Requester: Desirable Requested by: Denys Rtveliashvili (rtvd) Partner organization: openSUSE.org Description: Remove the requirement for mount points like "/", "/home", ... to be on unencrypted partition. Ability to choose the desired level of encryption for such partitions would also be great. Use Case: The user wants to have a plain setup where he has as much of the disk encrypted as possible. There is no way to do it without keeping "/boot" unencrypted but the rest should be encrypted. The user does not want to use LVM as LVM is another level of indirection with its own quirks. Business case (Partner benefit): openSUSE.org: Currently the only practical way to have an (almost) full disk encryption would be to wrap everything in an encrypted LVM container. Just like any other software LVM has (and will have) its problems. Demanding the use of it means forcing the users to experience all those problems in addition to the rest. LVM is poorly documented. The documentation explains how to manage the volumes but is never specific on how well does it support optional (yet critical) features of block devices. In particular, serving as a non-trivial level of indirection, LVM might not propagate cache flushes, TRIM/DISCARD commands, may report incorrect "optimal size" for SSDs, etc. As a result it may appear like everything is all right, but the actual safety and performance of the storage can be severely degraded. -- openSUSE Feature: https://features.opensuse.org/314904

1 0

[openFATE 300758] Show unneeded packages
by fate_noreply＠suse.de 11 Mar '13

11 Mar '13

Feature changed by: Michael Schröder (mlschroe) Feature #300758, revision 149 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-11.3: Done Priority Requester: Desirable Projectmanager: Important Requested by: JP Rosevear (jproseve) Partner organization: openSUSE.org 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. #46: Moqi Ba (bamoqi) (2011-07-24 01:37:08) This FATE is marked as done but as of 11.4 "zypper rm -u" doesn't work without a package name. It cannot actively find and remove orphaned package which are auto-installed, like "apt-get autoremove" does. #47: Michael Schröder (mlschroe) (2012-02-13 12:34:53) (reply to #46) True. We can add that for 12.2, but the quality of the result really depends on knowing which packages were selected by the user and which packages were dragged in via dependencies. #49: Cristian Morales Vega (reddwarf) (2012-04-11 16:06:31) (reply to #47) That info is available already through the history, isn't? The only problem I know of is bnc#679213... that I have no idea if was fixed since the info is not public :-( #50: Jiri Srain (jsrain) (2012-08-21 11:52:03) (reply to #49) I have this information in the log of my 12.1. #54: Michael Schröder (mlschroe) (2012-12-20 16:29:00) (reply to #47) Just for completeness: 12.2 has an "unneded packages" package group. #48: Joachim Plack (jplack) (2012-02-13 13:58:53) For images generated in a SLEPOS environment, we would like the to reduce the footprint. So we'd like to find out all packages where last use (per read access time stamp) <= install time. This list we would the transfer back to the image creation server so that the next image gets reduce to what we really need. Btw. removedthe big list of rejected openSUSEs besides the first and last to get a better overview again while keeping the history #51: Jiri Srain (jsrain) (2012-08-21 11:54:04) (reply to #48) Jack, does this necessarily involve libzypp/zypper? I think that this is a rather specific use-case, which can be scripted easily. Besides, I suggest to handle this as a separate request - this one is about unneeded, not about unused. #55: Christian Kujau (ckujau) (2013-03-11 10:05:50) Why is this ticket set to "Done" (for openSUSE-11.3) - has this feature been implemented. I could not find anything related in zypper(8) in 12.3 - is a new ticket required to have this resolved? A possible (but possibly dangerous) workaround would be to use YUM: $ zypper install yum-utils $ zypper remove --dry-run `package-cleanup --quiet --leaves` The "--oldkernels" isn't working here though: package-cleanup --oldkernels Setting up yum Traceback (most recent call last): File "/usr/bin/package-cleanup", line 419, in <module> main() File "/usr/bin/package-cleanup", line 388, in main removeKernels(my, opts.kernelcount, opts.confirmed, opts.keepdevel) File "/usr/bin/package-cleanup", line 293, in removeKernels (kver,krel) = runningkernel.split('-') ValueError: too many values to unpack + #56: Michael Schröder (mlschroe) (2013-03-11 10:58:37) (reply to #55) + There's both "zypper remove --clean deps" and a "unneeded packages" + group in YaST. -- openSUSE Feature: https://features.opensuse.org/300758

1 0

[openFATE 300758] Show unneeded packages
by fate_noreply＠suse.de 11 Mar '13

11 Mar '13

Feature changed by: Christian Kujau (ckujau) Feature #300758, revision 148 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-11.3: Done Priority Requester: Desirable Projectmanager: Important Requested by: JP Rosevear (jproseve) Partner organization: openSUSE.org 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. #46: Moqi Ba (bamoqi) (2011-07-24 01:37:08) This FATE is marked as done but as of 11.4 "zypper rm -u" doesn't work without a package name. It cannot actively find and remove orphaned package which are auto-installed, like "apt-get autoremove" does. #47: Michael Schröder (mlschroe) (2012-02-13 12:34:53) (reply to #46) True. We can add that for 12.2, but the quality of the result really depends on knowing which packages were selected by the user and which packages were dragged in via dependencies. #49: Cristian Morales Vega (reddwarf) (2012-04-11 16:06:31) (reply to #47) That info is available already through the history, isn't? The only problem I know of is bnc#679213... that I have no idea if was fixed since the info is not public :-( #50: Jiri Srain (jsrain) (2012-08-21 11:52:03) (reply to #49) I have this information in the log of my 12.1. #54: Michael Schröder (mlschroe) (2012-12-20 16:29:00) (reply to #47) Just for completeness: 12.2 has an "unneded packages" package group. #48: Joachim Plack (jplack) (2012-02-13 13:58:53) For images generated in a SLEPOS environment, we would like the to reduce the footprint. So we'd like to find out all packages where last use (per read access time stamp) <= install time. This list we would the transfer back to the image creation server so that the next image gets reduce to what we really need. Btw. removedthe big list of rejected openSUSEs besides the first and last to get a better overview again while keeping the history #51: Jiri Srain (jsrain) (2012-08-21 11:54:04) (reply to #48) Jack, does this necessarily involve libzypp/zypper? I think that this is a rather specific use-case, which can be scripted easily. Besides, I suggest to handle this as a separate request - this one is about unneeded, not about unused. + #55: Christian Kujau (ckujau) (2013-03-11 10:05:50) + Why is this ticket set to "Done" (for openSUSE-11.3) - has this feature + been implemented. I could not find anything related in zypper(8) in + 12.3 - is a new ticket required to have this resolved? A possible (but + possibly dangerous) workaround would be to use YUM: + $ zypper install yum-utils + $ zypper remove --dry-run `package-cleanup --quiet --leaves` + The "--oldkernels" isn't working here though: + package-cleanup --oldkernels + Setting up yum + Traceback (most recent call last): + File "/usr/bin/package-cleanup", line 419, in <module> + main() + File "/usr/bin/package-cleanup", line 388, in main + removeKernels(my, opts.kernelcount, opts.confirmed, opts.keepdevel) + File "/usr/bin/package-cleanup", line 293, in removeKernels + (kver,krel) = runningkernel.split('-') + ValueError: too many values to unpack -- openSUSE Feature: https://features.opensuse.org/300758

1 0

[New: openFATE 314418] User management reworked
by fate_noreply＠suse.de 08 Mar '13

08 Mar '13

Feature added by: Adrian Schröter (adrianSuSE) Feature #314418, revision 1 Title: User management reworked Buildservice: Evaluation by engineering manager Milestone: 2.4 Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Adrian Schröter (adriansuse) Partner organization: openSUSE.org Description: As part of the Rails 3.2 port of OBS we need to re-do the interfaces for user and group managenment. They should get implemented in the webui now instead in the api part. -- openSUSE Feature: https://features.opensuse.org/314418

1 2

[openFATE 303793] Mount /var/run as tmpfs
by fate_noreply＠suse.de 07 Mar '13

07 Mar '13

Feature changed by: Jiri Srain (jsrain) Feature #303793, revision 64 Title: Mount /var/run as tmpfs openSUSE-11.2: Rejected by Matthias Eckermann (mge1512) reject date: 2009-07-16 11:42:53 reject reason: Rejected on request of Engineering. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.3: Rejected by Andreas Jaeger (a_jaeger) reject date: 2010-10-06 16:02:09 reject reason: not done. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.4: Done Priority Requester: Mandatory Requested by: Kay Sievers (kay_sievers) Technical Contact: Kay Sievers (kay_sievers) Partner organization: openSUSE.org Description: /var/run should be mounted as tmpfs. This would avoid the cleaning of stale files or sockets on bootup and avoid atime updates of any mounted filesystems. This is required for eg powermanagement, which currently wakes up the system from any idle states for a socket operation. Services must be modified not to depend on a preexisting content in /var/run upon startup. RPMs must be modified to not place anything there. Discussion: #2: Federico Lucifredi (flucifredi) (2008-07-08 19:30:23) somehow SLES/SLED got out of sync here. Matching. #4: Duncan Mac-Vicar (dmacvicar) (2008-07-14 15:30:03) There are no resources for this feature. Please postpone, (as agreed with MgE) #5: Duncan Mac-Vicar (dmacvicar) (2008-07-14 15:46:55) Just as a side note this feature will require an effort of aprox. 1 week, together with #303810 (they averlap about 95%) #10: Arvin Schnell (aschnell) (2009-02-04 10:50:32) Any requirements on the size for the tmpfs or should the default of tmpfs be used? #11: Arvin Schnell (aschnell) (2009-02-05 19:27:03) (reply to #10) Kay replied by personal mail: Size doesn't matter. /var/lock should also be on tmpfs. #12: Duncan Mac-Vicar (dmacvicar) (2009-06-02 11:22:49) Christoph, please reject with openSUSE 11.2, because disk encryption we can't promise this feature for 11.2. It may get done as bonus if encryption gets done earlier than expected, but we can't commit to it (which is what rejection means, which does not mean we may work on it). It is the next thing we will work on after encryption support. #32: Dirk Mueller (dirkmueller) (2010-04-26 12:08:04) rpmlint check implemented (badness 900) #35: Duncan Mac-Vicar (dmacvicar) (2010-11-03 15:50:03) Kay, is this still feature desired now with relatime as default? or can be closed forever? #36: Kay Sievers (kay_sievers) (2010-11-03 18:52:22) (reply to #35) It is a good feature to have, because we don't want to cleanup the dir on bootup. Systemd has this mandatory and you can't even disable it. #37: Andreas Jaeger (a_jaeger) (2010-11-04 09:24:36) (reply to #35) This feature is done with using systemd. The scripts mount /var/run already and packages get fixed. I don't think any changes in YaST are needed, so I guess this can be marked as done. Duncan, please check for YaST work - and if none is needed, mark as done. #38: Arvin Schnell (aschnell) (2010-11-04 12:02:02) (reply to #37) When systemd mounts it and no entry in fstab is desired the feature is done from my side. I'm sure the mounting happens after potentially mounting /var. #39: Duncan Mac-Vicar (dmacvicar) (2013-03-05 11:29:23) Jiri, assuming SLE12 uses systemd, this feature can be marked as done. - #40: Jiri Srain (jsrain) (2013-03-07 13:46:05) (reply to #39) - Matthias, is it decided that SLES12 will use systemd, or are there - still some alternatives? -- openSUSE Feature: https://features.opensuse.org/303793

1 0

[New: openFATE 314350] Cloud backup
by fate_noreply＠suse.de 07 Mar '13

07 Mar '13

Feature added by: David Disseldorp (dmdiss) Feature #314350, revision 1 Title: Cloud backup openSUSE Distribution: Unconfirmed Priority Requester: Desirable Requested by: David Disseldorp (dmdiss) Partner organization: openSUSE.org Description: openSUSE currently includes a useful system backup module for creating archives of user and system files. Backup archives can be stored locally or on a remote NFS share. An improvement would be to allow users to store backup archives at a cloud storage location. I propose making use of the Elasto cloud storage library to implement this: http://oss.sgi.com/cgi-bin/gitweb.cgi?p=ddiss/elasto -- openSUSE Feature: https://features.opensuse.org/314350

1 1

[openFATE 303793] Mount /var/run as tmpfs
by fate_noreply＠suse.de 07 Mar '13

07 Mar '13

Feature changed by: Jiri Srain (jsrain) Feature #303793, revision 63 Title: Mount /var/run as tmpfs openSUSE-11.2: Rejected by Matthias Eckermann (mge1512) reject date: 2009-07-16 11:42:53 reject reason: Rejected on request of Engineering. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.3: Rejected by Andreas Jaeger (a_jaeger) reject date: 2010-10-06 16:02:09 reject reason: not done. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.4: Done Priority Requester: Mandatory Requested by: Kay Sievers (kay_sievers) Technical Contact: Kay Sievers (kay_sievers) Partner organization: openSUSE.org Description: /var/run should be mounted as tmpfs. This would avoid the cleaning of stale files or sockets on bootup and avoid atime updates of any mounted filesystems. This is required for eg powermanagement, which currently wakes up the system from any idle states for a socket operation. Services must be modified not to depend on a preexisting content in /var/run upon startup. RPMs must be modified to not place anything there. Discussion: #2: Federico Lucifredi (flucifredi) (2008-07-08 19:30:23) somehow SLES/SLED got out of sync here. Matching. #4: Duncan Mac-Vicar (dmacvicar) (2008-07-14 15:30:03) There are no resources for this feature. Please postpone, (as agreed with MgE) #5: Duncan Mac-Vicar (dmacvicar) (2008-07-14 15:46:55) Just as a side note this feature will require an effort of aprox. 1 week, together with #303810 (they averlap about 95%) #10: Arvin Schnell (aschnell) (2009-02-04 10:50:32) Any requirements on the size for the tmpfs or should the default of tmpfs be used? #11: Arvin Schnell (aschnell) (2009-02-05 19:27:03) (reply to #10) Kay replied by personal mail: Size doesn't matter. /var/lock should also be on tmpfs. #12: Duncan Mac-Vicar (dmacvicar) (2009-06-02 11:22:49) Christoph, please reject with openSUSE 11.2, because disk encryption we can't promise this feature for 11.2. It may get done as bonus if encryption gets done earlier than expected, but we can't commit to it (which is what rejection means, which does not mean we may work on it). It is the next thing we will work on after encryption support. #32: Dirk Mueller (dirkmueller) (2010-04-26 12:08:04) rpmlint check implemented (badness 900) #35: Duncan Mac-Vicar (dmacvicar) (2010-11-03 15:50:03) Kay, is this still feature desired now with relatime as default? or can be closed forever? #36: Kay Sievers (kay_sievers) (2010-11-03 18:52:22) (reply to #35) It is a good feature to have, because we don't want to cleanup the dir on bootup. Systemd has this mandatory and you can't even disable it. #37: Andreas Jaeger (a_jaeger) (2010-11-04 09:24:36) (reply to #35) This feature is done with using systemd. The scripts mount /var/run already and packages get fixed. I don't think any changes in YaST are needed, so I guess this can be marked as done. Duncan, please check for YaST work - and if none is needed, mark as done. #38: Arvin Schnell (aschnell) (2010-11-04 12:02:02) (reply to #37) When systemd mounts it and no entry in fstab is desired the feature is done from my side. I'm sure the mounting happens after potentially mounting /var. #39: Duncan Mac-Vicar (dmacvicar) (2013-03-05 11:29:23) Jiri, assuming SLE12 uses systemd, this feature can be marked as done. + #40: Jiri Srain (jsrain) (2013-03-07 13:46:05) (reply to #39) + Matthias, is it decided that SLES12 will use systemd, or are there + still some alternatives? -- openSUSE Feature: https://features.opensuse.org/303793

1 0

[openFATE 308626] Snapshot/Rollback interface to the ZYpp stack
by fate_noreply＠suse.de 05 Mar '13

05 Mar '13

Feature changed by: Duncan Mac-Vicar (dmacvicar) Feature #308626, revision 57 Title: Snapshot/Rollback interface to the ZYpp stack openSUSE-11.3: Rejected by Gerald Pfeifer (geraldpfeifer) reject date: 2010-11-17 00:53:34 reject reason: openSUSE 11.3 has been released months ago. Priority Requester: Mandatory - openSUSE-11.4: New + openSUSE-11.4: Rejected by Duncan Mac-Vicar (dmacvicar) + reject date: 2013-03-05 17:37:32 + reject reason: not done for 11.4 but later Priority Requester: Important openSUSE 12.1: Done Priority Requester: Important Requested by: Duncan Mac-Vicar (dmacvicar) - Product Manager: Federico Lucifredi (flucifredi) 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 packages: libzypp snapper zypper 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. #9: Olaf Kirch (okir) (2010-10-22 12:56:49) (reply to #7) My preferred solution would be to enable grub1 for btrfs; it seems to pose the least risk - assuming the btrfs code is stable enough. (BTW either my fate client is too old, or the link you added is broken). #13: Gerald Pfeifer (geraldpfeifer) (2010-11-17 00:53:01) One further idea that came up is adding a bootloader entry (or several) that, when chosen, would revert the system into an old state as represented/described by that entry and boot into it. This is more involved than the more basic scenarios here and might be suitable for another, linked FATE? #15: Federico Lucifredi (flucifredi) (2011-03-25 21:02:37) (reply to #13) I like that. If at all possible, we should provide a boot item into the previous snapshot. #14: Jörg Schmela (herz-von-hessen) (2011-02-25 18:42:40) therefore my full Consent #18: Michael Andres (mlandres) (2011-06-28 12:32:03) libzypp ability to execute pre/post commit plugin scripts is done (see http://doc.opensuse.org/projects/libzypp/HEAD/plugin-commit.html). Arvin is about to provide the snapper plugin, which actually takes the snapshots. #19: Arvin Schnell (aschnell) (2011-06-29 10:12:38) (reply to #18) I have now added a python-plugin for zypp that calls snapper pre and post to commits. I was told that this is all we provide for SLE11 SP2 so I'm setting this feature to Done although many more ideas are mentioned here. #20: Duncan Mac-Vicar (dmacvicar) (2011-09-21 13:33:56) State was wrong. ZYpp does not support this on 11.4. Set it to done on 12.1. Coolo, can you reject for 11.4? -- openSUSE Feature: https://features.opensuse.org/308626

1 0

[New: openFATE 308285] Easy way to switch from 11.2 to Factory Repositories - and to 11.3
by fate_noreply＠suse.de 05 Mar '13

05 Mar '13

Feature added by: Andreas Jaeger (a_jaeger) Feature #308285, revision 1 Title: Easy way to switch from 11.2 to Factory Repositories - and to 11.3 openSUSE-11.3: Evaluation Priority Requester: Mandatory Requested by: Andreas Jaeger (a_jaeger) Description: Right now, I have to manually change the repositories when upgrading from 11.2 to Factory - or from Factory to 11.3. I'd like to have an easy way, e.g. 1-Click-Install or a script that does this automatically for my system. This might not change external repositories, e.g. on the Build Service, but it should change the official distribution repositories. -- openSUSE Feature: https://features.opensuse.org/308285

1 5