March 2011 - openSUSE Features - openSUSE Mailing Lists

[openFATE 305877] Popularity contest
by fate_noreply＠suse.de 31 Mar '11

31 Mar '11

Feature changed by: Ionuț Arțăriși (mapleoin) Feature #305877, revision 37 Title: Popularity contest openSUSE-11.2: Rejected by Stephan Kulow (coolo) reject date: 2009-09-07 13:57:05 reject reason: No update, too late for 11.2 - and for the future I would rather see it integrated into smolt Priority Requester: Important Projectmanager: Desirable openSUSE-11.3: Rejected by Andreas Jaeger (a_jaeger) reject date: 2010-11-04 14:42:00 reject reason: Not done. Priority Requester: Desirable openSUSE-11.4: New Priority Requester: Important Requested by: Vladimir Nadvornik (nadvornik) Product Manager: (Novell) Project Manager: (Novell) Engineering Manager: (Novell) Developer: (Novell) Partner organization: openSUSE.org Description: We need a feedback about packages that are preferred by users and actively used. Debian already has a tool named Popularity contest (popcon) * reusing popcon will give us results that are directly comparable with Debian and Ubuntu * packagers team can take care of the package * we need a configuration dialog in YaST that is visible enough * we need a server infrastructure on opensuse.org. (There are certain privacy issues, see Debian FAQ for details) References: http://en.opensuse.org/BrainStorming_Prague#We_don.27t_know_which_packages_… http://popcon.debian.org/FAQ http://popcon.debian.org/ http://popcon.ubuntu.com/ Discussion: #1: Michal Vyskocil (mvyskocil) (2009-02-20 12:56:06) The pupularity-contest executable is a simple Perl script, which should be ported to rpm (replacing of dpkg calls by appropiate rpm alternative should be enough). #2: Pavol Rusnak (prusnak) (2009-03-11 15:53:13) (reply to #1) Replacing of dpkg calls with rpm is a no-go, because of the transactions in RPM. I started to work on a rewrite, will post results soon ... #3: Marek Stopka (m4r3k) (2009-03-13 09:28:08) (reply to #2) And here is a result... :-) http://stick.gk2.sk/blog/2009/03/popcorn-popularity-contest-for-rpm/ #4: Jay Mistry (zmdmw52) (2009-03-15 15:36:25) The software equivalent of Smolts Hardware profiler. Results can be uploaded to a dedicated website (such as is for Smolts- http://www.smolts.org/) so that users can see the relative weight/popularity of various commonly-used applications. #7: Carlos Gonçalves (cgoncalves) (2009-07-25 19:03:58) (reply to #4) There is a GSOC project (http://socghop.appspot.com/student_project/show/google/gsoc2009/gentoo/t124…) which is addressing this (Smolt) feature to Gentoo, though the author has been coding this aswell to Debian-based distros and more recently considering RPM distros too. I've been working with him on the client integration since I'm its author, and from my side all I can say is that Smolt sooner or later will be addressing this feature, too, but won't be ready in time for openSUSE 11.2 since feature/version freeze is next week (July 31). #5: T. J. Brumfield (enderandrew) (2009-06-13 21:16:54) During install, there can be a simple checkbox such as "Share hardware/software details with openSUSE servers for profiling." #6: Stephan Kulow (coolo) (2009-06-24 11:29:15) first we need the package in and someone to maintain the server or contact debian if they host other distros too. #9: 6tr6tr 6tr6tr (6tr6tr) (2010-10-01 20:16:28) I would actually prefer that things not just have one ranking but: 1. Trustworthiness 2. Privacy 3. Reliability/Uptime/Speed 4. Popularity I think those are all important and very different requirements. + #10: Ionuț Arțăriși (mapleoin) (2011-03-31 13:31:57) + Is there anyone still working on this? AFAIU there is more work to be + done on the server. If that is correct, I might be able to help. -- openSUSE Feature: https://features.opensuse.org/305877

1 0

[New: openFATE 312150] weak conflicts/softlocks/no-recommends for patterns
by fate_noreply＠suse.de 31 Mar '11

31 Mar '11

Feature added by: Ludwig Nussel (lnussel) Feature #312150, revision 1 Title: weak conflicts/softlocks/no-recommends for patterns openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Ludwig Nussel (lnussel) Partner organization: openSUSE.org Description: Installation of a pattern also draws in packages that are not in the pattern but only recommended by those listed in the pattern. For the "minimal" pattern this behavior is not desirable though as one really wants a minimal installation without the optional stuff. Current workaround is to add conflicts to the unwanted, recommended packages. That has the disadvantage that explicitly installing such blocked packages requires deinstallation of the pattern. Therefore we need some mechanism to block recommended packages. I see several approaches: 1. introduce a weak-conflicts/soft-locks tag in patterns. This tag must be stronger than the recommends tag of packages. 2. add a no-recommends tag to the pattern which would cause the resolver to not honor recommends while installing the pattern 3. add a workaround to yast and hardcode setting the no-recommends flag when the user selects the minimal pattern. -- openSUSE Feature: https://features.opensuse.org/312150

1 1

[openFATE 305336] Ship man page for every executable
by fate_noreply＠suse.de 29 Mar '11

29 Mar '11

Feature changed by: Kai Dupke (kdupke) Feature #305336, revision 62 Title: Ship man page for every executable openSUSE-11.2: Rejected by Andreas Jaeger (a_jaeger) reject date: 2009-08-11 15:41:47 reject reason: This is a task that should be done in cooperation with the upstream projects. Priority Requester: Mandatory openSUSE-11.4: Rejected by Matthias Eckermann (mge1512) reject date: 2011-03-26 09:25:38 reject reason: closing here, opening new Priority Requester: Important - Info Provider: (Novell) Requested by: Matthias Eckermann (mge1512) Product Manager: (Novell) Product Manager: (Novell) Project Manager: (Novell) Engineering Manager: (Novell) Partner organization: openSUSE.org Description: 1. Even graphical applications need docs outside the application itself. The need to run the application, to know what does it does, is not good. 2. You need a standard documentation format; where standard = expected for people needing that documentation. Who are, often, not knowing the distro well (so the format can't be distro-specific). And the format must be the same for all binaries/packages. One can't rely on the fact it will always be easy and intuitive to find that some application is part KDE (for example) and one can get the documentation in konqueror when typing 'help:/application'. 3. To view the documentation must be as easy as possible and with as minimal resources as possible. This is why online documentation is not so good (you need a running Internet net connection), documentation in a web browser as well (you need X and graphical desktop). HTML is questionable as it (as a format) allows so many extensions that it is needed to expect that such documentation will not be readable in text browsers after some time. 4. Many parts are shared between openSUSE and the enterprise products. And, in the enterprise world, we need to be much more standard conforming. Including the documentation. A UNIX admin will use the 'man' command for getting info about the binary. 'info' system is here as well, for many years. But 'man' is still more usual. Imagine a server room with hundreds/thousands of servers of several UN*X clones - 'man' works everywhere, and Linux is expected to be "on par" also with respect to those capabilities. These four points stay behind the idea of man pages needed and provided for everything. Relations: - How to Create Manpages with DocBook (url: http://en.opensuse.org/Manual_Pages/How_to_Create_Manpages_with_DocBook) - At http://en.opensuse.org/Manual_Pages/Missing a list of all packages with missing man pages can be found (url: http://en.opensuse.org/Manual_Pages/Missing) Use Case: User / Administrator should find a dedicated man page for every executable in openSUSE and SUSE Linux Enterprise systems. Discussion: #2: Stefan Behlert (sbehlert) (2008-10-22 15:00:11) I agree with the intention, but shouldn't it be rather 'documentation for each executable'? Newer stuff uses mostly info-pages, afaiks #3: Matthias Eckermann (mge1512) (2008-11-10 14:31:15) (reply to #2) It is valid to have a pointer to the info pages in the man-pages, sure. But man-pages are the UNIX proposed way of doing documentation. #9: Thomas Schraitle (thomas-schraitle) (2009-02-20 09:54:09) IMHO DocBook would be very suitable for this task as nobody has to learn the awkward syntax of groff/troff/... For example, I've submitted a DocBook file to the scout author and he generates the manpage with the DocBook stylesheets automatically. If you think, a manpage is not enough, each DocBook file can be easily transformed into (X)HTML, PDF, or almost any other output formats. IHMO it saves time if you want to support more formats than just manpage. The whole process is documented here: http://en.opensuse.org/Manual_Pages/How_to_Create_Manpages_with_DocBook #10: Jan Engelhardt (jengelh) (2009-02-21 20:31:14) (reply to #9) Manpages are very suitable for this task as nobody has to learn the awkward DocBook syntax. If done right, manpages are just another markup language and there are just a few elements one needs to know. (You can even count them in your hands: .TH, .SH, .SS, .PP, .TP, .nf/.fi, \fB, \fI, \fP, and sometimes . IP. They almost map to HTML's title, h1, h2, p, (no direct eqv), pre, b, i, /b|/i, and ol|ul, respectively.) #11: Praveen Kunjapur (stilo_vingyou) (2009-04-09 21:38:39) Knowledge is power. #13: Thorsten Kukuk (kukuk) (2009-08-17 22:17:33) We have a huge amount of orphaned packages, there is no chance to do any additional work on this feature. #21: Juergen Weigert (jnweiger) (2009-09-07 17:36:35) No. I cannot even estimate what the docimpact might be. Someone please collect a list of executables, and describe what kind of work is expected on them. Then we can make estimates. From the above comments #13 to #18 I cannot extract useful information. #22: Thorsten Kukuk (kukuk) (2009-09-10 09:53:11) It is still not clear to me what PM is expecting. For adding all the manual pages to every single RPM we don't have the resources, meanwhile the strategy and resource situation changed dramatically. And touching all RPMs would mean, that an online update is nearly impossible, customers have to download nearly every installed RPM. Else I can only repeat my comment #15 #34: Thomas Schraitle (thomas-schraitle) (2009-09-10 14:29:21) I don't think some issues in this entry are really covered yet -- apart from any future decision: 1) Writing manpages for all executables is illusionary. This task has to be and can only be handled by the corresponding upstream projects. Maybe you can convince the project maintainers to improve their documentation in this regard or support them with trainees or the like. But it's a longterm goal, not something done between two months. 2) Firefox is an executable. Does it need a manpage? I would say no, it has other documentation. What qualifies an executable to get a manpage? Where do you draw the line? 3) Writing a manpage is one thing, maintaining it is another. As experience shows, sometimes you have significant changes between one version and the other. Which should be covered in the manpage, of course. Again, this can not be done inhouse, it is a task which can only be written by the upstream projects accordingly. 4) As already written in comment #21, no list is/was collected. 5) As outlined, IHMO documentation departement is the wrong addressee. #35: Matthias Eckermann (mge1512) (2009-09-10 14:53:27) (reply to #34) >I don't think some issues in this entry are really covered yet -- apart from any future decision: Be sure that this has been discussed already in depth, e.g. by the PM Team within SUSE/Novell. > Writing manpages for all executables is illusionary. This task has to be and > can only be handled by the corresponding upstream projects. Man pages do exist for most binaries in the open source community, many also independendly of the respective projects. The Debian community has done a great job here, and it could be useful to join the forces of openSUSE community with Debian here. ... > Maybe you can convince the project maintainers to improve their documentation in > this regard or support them with trainees or the like. But it's a longterm goal, > not something done between two months. That's why the feature already exists for one year, ... > Firefox is an executable. Does it need a manpage? I would say no, > it has other documentation. What qualifies an executable to get > a manpage? Where do you draw the line? In the Enterprise world every binary needs a man page. Including Firefox and all Gnome and KDE applications. One reason for that: no administrator wants to have binaries around, where (s)he cannot say, what it is used for. This might also be a matter of "compliance". I agree however that this is different for openSUSE and the community. > Writing a manpage is one thing, maintaining it is another. > As experience shows, sometimes you have significant changes between > one version and the other. Which should be covered in the manpage, of course. > Again, this can not be done inhouse, it is a task which can only be written > by the upstream projects accordingly. Agreed. > As already written in comment #21, no list is/was collected. This is wrong. In the package "man-pages-supplement" a script exists, to list all binaries without a man-page already. Thus the analysis itself is not difficult. The doing is the challenge. Indeed. #37: Pavol Rusnak (prusnak) (2009-09-10 14:54:24) (reply to #34) 2. EVERY executable, the title of the feature says it all. Even if the manpage only contains "Firefox is a web browser" it is better than nothing. 4. Wrong, list is attached as external reference - http://en.opensuse.org/Manual_Pages/Missing (I collected it in February 2009, so it is a little bit outdated). 5. I don't think this could be done in one departement, because this is huge amount of work. We could start adopting already written manpages from Debian, but still a longterm issue. #38: Thomas Schraitle (thomas-schraitle) (2009-09-10 15:32:43) (reply to #37) > 4. Wrong, list is attached as external reference - http://en.opensuse.org/Manual_Pages/Missing (I collected it in February 2009, so it is a little bit outdated). Thanks Pavol, for the reminder. The list is one part and we know what's missing. That's good. However, what we don't know is the effort/amount of work to make it. It can be a very short one, or something that is really complicated and you need special knowledge. Maybe some could be autogenerated. -- openSUSE Feature: https://features.opensuse.org/305336

1 0

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

28 Mar '11

Feature changed by: Lukas Ocilka (locilka) Feature #308626, revision 37 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: Evaluation by project manager Priority Requester: Important Info Provider: (Novell) Info Provider: (Novell) Info Provider: (Novell) Info Provider: (Novell) Requested by: Duncan Mac-Vicar (dmacvicar) Product Manager: (Novell) Product Manager: (Novell) Project Manager: (Novell) Engineering Manager: (Novell) Engineering Manager: (Novell) Engineering Manager: (Novell) Developer: (Novell) - Developer: Ján Kupec (jkupec) Technical Contact: (Novell) Technical Contact: (Novell) Technical Contact: (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. #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 -- openSUSE Feature: https://features.opensuse.org/308626

1 0

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

28 Mar '11

Feature changed by: Jiri Srain (jsrain) Feature #308626, revision 36 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: Evaluation by engineering manager + openSUSE-11.4: Evaluation by project manager Priority Requester: Important - Projectmanager: Mandatory Info Provider: (Novell) Info Provider: (Novell) Info Provider: (Novell) Info Provider: (Novell) Requested by: Duncan Mac-Vicar (dmacvicar) Product Manager: (Novell) Product Manager: (Novell) Project Manager: (Novell) Engineering Manager: (Novell) Engineering Manager: (Novell) Engineering Manager: (Novell) Developer: (Novell) Developer: Ján Kupec (jkupec) Technical Contact: (Novell) Technical Contact: (Novell) Technical Contact: (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. #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 -- openSUSE Feature: https://features.opensuse.org/308626

1 0

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

28 Mar '11

Feature changed by: Jiri Srain (jsrain) Feature #308626, revision 35 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: Evaluation by project manager + openSUSE-11.4: Evaluation by engineering manager Priority Requester: Important + Projectmanager: Mandatory Info Provider: (Novell) Info Provider: (Novell) Info Provider: (Novell) Info Provider: (Novell) Requested by: Duncan Mac-Vicar (dmacvicar) Product Manager: (Novell) Product Manager: (Novell) Project Manager: (Novell) Engineering Manager: (Novell) Engineering Manager: (Novell) + Engineering Manager: (Novell) Developer: (Novell) Developer: Ján Kupec (jkupec) Technical Contact: (Novell) Technical Contact: (Novell) Technical Contact: (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. #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 -- openSUSE Feature: https://features.opensuse.org/308626

1 0

[New: openFATE 309088] zsync support for update channel refresh
by fate_noreply＠suse.de 26 Mar '11

26 Mar '11

Feature added by: Dirk Mueller (dirkmueller) Feature #309088, revision 1 Title: zsync support for update channel refresh openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Dirk Mueller (dirkmueller) Partner organization: openSUSE.org Description: For every released maintenance update, the repodata/primary.xml.gz file grows by a bit (depending on the number of dependencies etc for every released package). To smoothen updater-experience and reduce the amount of data that has to be download for an update-repo refresh, the diff of the file should be downloaded by using zsync. In addition the repo-channel generation script has to run zsyncmake and gzip --rsyncable. Business case (Partner benefit): openSUSE.org: With openSUSE 11.2, the primary.xml.gz size grows by 1.1MB for every released kernel, and currently the file has to be downloaded completely upon every change (due to xml.gz compression). -- openSUSE Feature: https://features.opensuse.org/309088

1 6

[openFATE 305336] Ship man page for every executable
by fate_noreply＠suse.de 26 Mar '11

26 Mar '11

Feature changed by: Matthias Eckermann (mge1512) Feature #305336, revision 61 Title: Ship man page for every executable openSUSE-11.2: Rejected by Andreas Jaeger (a_jaeger) reject date: 2009-08-11 15:41:47 reject reason: This is a task that should be done in cooperation with the upstream projects. Priority Requester: Mandatory - openSUSE-11.4: Evaluation by product manager + openSUSE-11.4: Rejected by Matthias Eckermann (mge1512) + reject date: 2011-03-26 09:25:38 + reject reason: closing here, opening new Priority Requester: Important Info Provider: (Novell) - Info Provider: (Novell) Requested by: Matthias Eckermann (mge1512) Product Manager: (Novell) Product Manager: (Novell) Project Manager: (Novell) Engineering Manager: (Novell) Partner organization: openSUSE.org Description: 1. Even graphical applications need docs outside the application itself. The need to run the application, to know what does it does, is not good. 2. You need a standard documentation format; where standard = expected for people needing that documentation. Who are, often, not knowing the distro well (so the format can't be distro-specific). And the format must be the same for all binaries/packages. One can't rely on the fact it will always be easy and intuitive to find that some application is part KDE (for example) and one can get the documentation in konqueror when typing 'help:/application'. 3. To view the documentation must be as easy as possible and with as minimal resources as possible. This is why online documentation is not so good (you need a running Internet net connection), documentation in a web browser as well (you need X and graphical desktop). HTML is questionable as it (as a format) allows so many extensions that it is needed to expect that such documentation will not be readable in text browsers after some time. 4. Many parts are shared between openSUSE and the enterprise products. And, in the enterprise world, we need to be much more standard conforming. Including the documentation. A UNIX admin will use the 'man' command for getting info about the binary. 'info' system is here as well, for many years. But 'man' is still more usual. Imagine a server room with hundreds/thousands of servers of several UN*X clones - 'man' works everywhere, and Linux is expected to be "on par" also with respect to those capabilities. These four points stay behind the idea of man pages needed and provided for everything. Relations: - How to Create Manpages with DocBook (url: http://en.opensuse.org/Manual_Pages/How_to_Create_Manpages_with_DocBook) - At http://en.opensuse.org/Manual_Pages/Missing a list of all packages with missing man pages can be found (url: http://en.opensuse.org/Manual_Pages/Missing) Use Case: User / Administrator should find a dedicated man page for every executable in openSUSE and SUSE Linux Enterprise systems. Discussion: #2: Stefan Behlert (sbehlert) (2008-10-22 15:00:11) I agree with the intention, but shouldn't it be rather 'documentation for each executable'? Newer stuff uses mostly info-pages, afaiks #3: Matthias Eckermann (mge1512) (2008-11-10 14:31:15) (reply to #2) It is valid to have a pointer to the info pages in the man-pages, sure. But man-pages are the UNIX proposed way of doing documentation. #9: Thomas Schraitle (thomas-schraitle) (2009-02-20 09:54:09) IMHO DocBook would be very suitable for this task as nobody has to learn the awkward syntax of groff/troff/... For example, I've submitted a DocBook file to the scout author and he generates the manpage with the DocBook stylesheets automatically. If you think, a manpage is not enough, each DocBook file can be easily transformed into (X)HTML, PDF, or almost any other output formats. IHMO it saves time if you want to support more formats than just manpage. The whole process is documented here: http://en.opensuse.org/Manual_Pages/How_to_Create_Manpages_with_DocBook #10: Jan Engelhardt (jengelh) (2009-02-21 20:31:14) (reply to #9) Manpages are very suitable for this task as nobody has to learn the awkward DocBook syntax. If done right, manpages are just another markup language and there are just a few elements one needs to know. (You can even count them in your hands: .TH, .SH, .SS, .PP, .TP, .nf/.fi, \fB, \fI, \fP, and sometimes . IP. They almost map to HTML's title, h1, h2, p, (no direct eqv), pre, b, i, /b|/i, and ol|ul, respectively.) #11: Praveen Kunjapur (stilo_vingyou) (2009-04-09 21:38:39) Knowledge is power. #13: Thorsten Kukuk (kukuk) (2009-08-17 22:17:33) We have a huge amount of orphaned packages, there is no chance to do any additional work on this feature. #21: Juergen Weigert (jnweiger) (2009-09-07 17:36:35) No. I cannot even estimate what the docimpact might be. Someone please collect a list of executables, and describe what kind of work is expected on them. Then we can make estimates. From the above comments #13 to #18 I cannot extract useful information. #22: Thorsten Kukuk (kukuk) (2009-09-10 09:53:11) It is still not clear to me what PM is expecting. For adding all the manual pages to every single RPM we don't have the resources, meanwhile the strategy and resource situation changed dramatically. And touching all RPMs would mean, that an online update is nearly impossible, customers have to download nearly every installed RPM. Else I can only repeat my comment #15 #34: Thomas Schraitle (thomas-schraitle) (2009-09-10 14:29:21) I don't think some issues in this entry are really covered yet -- apart from any future decision: 1) Writing manpages for all executables is illusionary. This task has to be and can only be handled by the corresponding upstream projects. Maybe you can convince the project maintainers to improve their documentation in this regard or support them with trainees or the like. But it's a longterm goal, not something done between two months. 2) Firefox is an executable. Does it need a manpage? I would say no, it has other documentation. What qualifies an executable to get a manpage? Where do you draw the line? 3) Writing a manpage is one thing, maintaining it is another. As experience shows, sometimes you have significant changes between one version and the other. Which should be covered in the manpage, of course. Again, this can not be done inhouse, it is a task which can only be written by the upstream projects accordingly. 4) As already written in comment #21, no list is/was collected. 5) As outlined, IHMO documentation departement is the wrong addressee. #35: Matthias Eckermann (mge1512) (2009-09-10 14:53:27) (reply to #34) >I don't think some issues in this entry are really covered yet -- apart from any future decision: Be sure that this has been discussed already in depth, e.g. by the PM Team within SUSE/Novell. > Writing manpages for all executables is illusionary. This task has to be and > can only be handled by the corresponding upstream projects. Man pages do exist for most binaries in the open source community, many also independendly of the respective projects. The Debian community has done a great job here, and it could be useful to join the forces of openSUSE community with Debian here. ... > Maybe you can convince the project maintainers to improve their documentation in > this regard or support them with trainees or the like. But it's a longterm goal, > not something done between two months. That's why the feature already exists for one year, ... > Firefox is an executable. Does it need a manpage? I would say no, > it has other documentation. What qualifies an executable to get > a manpage? Where do you draw the line? In the Enterprise world every binary needs a man page. Including Firefox and all Gnome and KDE applications. One reason for that: no administrator wants to have binaries around, where (s)he cannot say, what it is used for. This might also be a matter of "compliance". I agree however that this is different for openSUSE and the community. > Writing a manpage is one thing, maintaining it is another. > As experience shows, sometimes you have significant changes between > one version and the other. Which should be covered in the manpage, of course. > Again, this can not be done inhouse, it is a task which can only be written > by the upstream projects accordingly. Agreed. > As already written in comment #21, no list is/was collected. This is wrong. In the package "man-pages-supplement" a script exists, to list all binaries without a man-page already. Thus the analysis itself is not difficult. The doing is the challenge. Indeed. #37: Pavol Rusnak (prusnak) (2009-09-10 14:54:24) (reply to #34) 2. EVERY executable, the title of the feature says it all. Even if the manpage only contains "Firefox is a web browser" it is better than nothing. 4. Wrong, list is attached as external reference - http://en.opensuse.org/Manual_Pages/Missing (I collected it in February 2009, so it is a little bit outdated). 5. I don't think this could be done in one departement, because this is huge amount of work. We could start adopting already written manpages from Debian, but still a longterm issue. #38: Thomas Schraitle (thomas-schraitle) (2009-09-10 15:32:43) (reply to #37) > 4. Wrong, list is attached as external reference - http://en.opensuse.org/Manual_Pages/Missing (I collected it in February 2009, so it is a little bit outdated). Thanks Pavol, for the reminder. The list is one part and we know what's missing. That's good. However, what we don't know is the effort/amount of work to make it. It can be a very short one, or something that is really complicated and you need special knowledge. Maybe some could be autogenerated. -- openSUSE Feature: https://features.opensuse.org/305336

1 0

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

26 Mar '11

Feature changed by: Federico Lucifredi (flucifredi) Feature #308626, revision 33 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: Evaluation by project manager Priority Requester: Important Info Provider: (Novell) Info Provider: (Novell) Info Provider: (Novell) Info Provider: (Novell) Requested by: Duncan Mac-Vicar (dmacvicar) Product Manager: (Novell) Product Manager: (Novell) Project Manager: (Novell) Engineering Manager: (Novell) Engineering Manager: (Novell) Developer: (Novell) Developer: Ján Kupec (jkupec) Technical Contact: (Novell) Technical Contact: (Novell) Technical Contact: (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. #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 -- openSUSE Feature: https://features.opensuse.org/308626

1 0

[New: openFATE 312100] tag packages for planned updates
by fate_noreply＠suse.de 24 Mar '11

24 Mar '11

Feature added by: Ludwig Nussel (lnussel) Feature #312100, revision 1 Title: tag packages for planned updates Buildservice: Unconfirmed Priority Requester: Mandatory Requested by: Ludwig Nussel (lnussel) Partner organization: openSUSE.org Description: We need a way to tag packages with bugzilla bugs so necessary fixes can be included on next package submission. That could be implemented using obs attributes. -- openSUSE Feature: https://features.opensuse.org/312100

1 0