- openSUSE Features

[openFate 303517] Automatically refreshing repositories at recurring intervals
by fate_noreply＠suse.de 16 Jan '09

16 Jan '09

Feature changed by: Robert Davies (robopensuse) Feature #303517, revision 25 Title: Automatically refreshing repositories at recurring intervals openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-09-12 14:12:10 reject reason: Postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Ladislav Slezak (lslezak) Interested: J. Daniel Schmidt (jdsn) Interested: Jiri Srain (jsrain) Interested: Jiří Suchomel (jsuchome) Partner organization: openSUSE.org Description: Autorefresh configured repositories at certain times, this could be on certain days, or time of day, etc. A mockup and more details are in https://bugzilla.novell.com/show_bug.cgi?id=346966 Discussion: #1: Federico Lucifredi (flucifredi) (2008-06-13 15:12:52) there are some caveats I can think of requiring silent fail (for instance, a laptop), or requiring randomization (not hitting NCC with a volley all at the same time), but I think the idea is good. #2: Duncan Mac-Vicar (dmacvicar) (2008-07-07 11:13:37) If you think you can make it work in a reliable way, please present a concept. Right now PackageKit and updater applets do refresh often before checking for updates so the system repos _are_ refreshed. So I don't see much value in this feature (unless a concept is presented). #3: Stanislav Visnovsky (visnov) (2008-07-07 12:34:19) (reply to #2) We have a concept in the automatic online update configuration. #4: Jiri Srain (jsrain) (2008-07-07 12:58:59) (reply to #3) You mean running online update from cron? It should involve metadata refresh, but I do not see any reason for a separate metadata download from cron. #5: Ladislav Slezak (lslezak) (2008-07-09 10:30:09) (reply to #4) The feature should allow to disable "autorefresh" flag for all repositories so the package management can be started quickly without connecting to network. The cronjob would keep the metadata uptodate. Of course, there might be a problem when metadata are changed too often on the server, but in my opinion that's not a usual case in the real world. #6: Jiri Srain (jsrain) (2008-07-10 12:16:08) Let's extend the "automatic online update" module so that it offers whether to do real automatic online update, or just refresh the metadata (via one check box) #8: J. Daniel Schmidt (jdsn) (2008-07-18 18:13:38) (reply to #6) This would hide the feature in an update related module. But the feature does not restrict this only to update repositories. Build- Service Repos might need a refresh as well or think of Factory. The right place for this feature is the Repository Manager. It has no relation to the update process or a configuration concerning updates. #7: Jiří Suchomel (jsuchome) (2008-07-14 14:46:01) Daniel, what's the status of the plan to merge "online update configuration" into registration module? #9: J. Daniel Schmidt (jdsn) (2008-07-18 18:15:46) (reply to #7) Currently I plan to merge it into a new module together with "Online Update Configuration" related settings. Please do not extend it with this unrelated repo refreshing dialog. #10: J. Daniel Schmidt (jdsn) (2008-09-10 19:48:24) Why am I listed as the only developer here? I just said that I will merge the modules "automatic online update setup" and "online update setup". This feature is requesting something completely different. #11: Duncan Mac-Vicar (dmacvicar) (2008-09-10 22:21:17) (reply to #10) Don't worry, this feature will be dropped as because the OnStar work. It is just abandoned. #13: Jiří Suchomel (jsuchome) (2008-09-11 08:20:55) (reply to #11) Really? I don't think so.This feature is aimed for opensuse (it wants to extend the current "online update setup"), while OnStar is for SLE. #12: Jiří Suchomel (jsuchome) (2008-09-11 08:22:02) (reply to #10) Because the requested feature would be part of what is currently "online update setup". And after the merge, I assumed you should mainain the merged parts. #15: J. Daniel Schmidt (jdsn) (2008-09-11 12:37:19) (reply to #12) No the requested feature will not be part of the successor of "online update setup". Maybe you want it to be. But IMHO this has nothing to do with anything that is called "online update *something*". This feature is about a general refresh of repositories - not just the update repo. Software repositories are handled in the "Software repositories" module. And thats the place where this feature is asking for enhancement. Just look at the linked bug (bnc#346966). It even has a mockup (yes, I added one as well, but just look at the original one). And this is now quite the same I already wrote in comment #8. #16: Jiří Suchomel (jsuchome) (2008-09-11 12:44:53) (reply to #15) Ah, sorry. Looks like I have some other feature in mind while commenting this one. This one really is not online-update specific. + #19: Robert Davies (robopensuse) (2009-01-16 16:30:40) + As when I go into Software Repository management, I am offered check + boxes like "autorefresh", it would seem when those boxes are checked, + that I expect this to happen without knowing about it. Being made to + wait, when I choose to run Online Update, or Software Management, seems + to defeat purpose of auto-refresh feature, though it is understandable + if no refresh was done for days. Some kind of cron job, ought to just + handle this. Why should the user be asked more questions than + "autorefresh" tick box? -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303517

1 0

[openFate 305168] default to relatime
by fate_noreply＠suse.de 16 Jan '09

16 Jan '09

Feature changed by: Robert Davies (robopensuse) Feature #305168, revision 7 Title: default to relatime openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-09-10 10:20:17 reject reason: This is too late for openSUSE 11.1. Postponing. Priority Requester: Mandatory openSUSE-11.2: New Priority Requester: Mandatory Requested by: Michael Meeks (michael_meeks) Interested: Guy Lunardi (glunardi) Interested: Jan Kara (jankara) Interested: Marcus Meissner (msmeissn) + Interested: Robert Davies (robopensuse) Partner organization: openSUSE.org Description: At least for desktops, we should reduce the memory and I/O thrash caused by atime updates, by using relatime. Relations: - bugreport from community (novell/bugzilla/id: 398616) https://bugzilla.novell.com/show_bug.cgi?id=398616 - Offers 'noatime' when 'relatime' is clearly better (novell/bugzilla/id: 461829) https://bugzilla.novell.com/show_bug.cgi?id=461829 + Discussion: + #1: Robert Davies (robopensuse) (2009-01-16 15:52:09) + Bug #461829 is not requesting breaking POSIX semantics by default! + relatime should replace noatime option in the mount options part of + partioner tool, especially now it has been improved to update atime on + file access if it's older than 24 hours. + Standards are important, and LRU file caches cannot be relied on if + noatime usage is common, or if poor backup software touches atimes, + when reading files. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305168

1 0

[openFate 300758] Show orphaned packages
by fate_noreply＠suse.de 16 Jan '09

16 Jan '09

Feature changed by: Andrey S (seld) Feature #300758, revision 37 Title: Show orphaned packages openSUSE-10.2: Rejected by Thorsten Kukuk <kukuk(a)novell.com> reject date: 2006-08-02 11:31:19 reject reason: For SL10.2 we have to get libzypp really stable and fast before we add new features. Priority Requester: Important openSUSE-10.3: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2007-07-17 17:03:57 reject reason: Postponing. Priority Requester: Important Projectmanager: Desirable openSUSE-11.0: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2007-11-21 12:16:20 reject reason: Out of scope for 11.0 Priority Requester: Important openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-07-07 13:34:02 reject reason: Postponing, needs underlaying infrastructure to be fixed first. Priority Requester: Important openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Stephan Binner (beineri) Interested: Andreas Jaeger (a_jaeger) + Interested: Andrey S (seld) Interested: Ján Kupec (jkupec) Interested: Matthias Eckermann (mge1512) Interested: Santiago Hirschfeld (jsantiagoh) Interested: Vincent Untz (vuntz) Partner organization: openSUSE.org Description: The package manager should learn to show orphanized packages (packages which are not required by other packages and are not in wanted selections) and allow to deinstall them like the popular debfoster/deborphan tools. A typical use case: user installs an application which pulls in some dependencies to test it, uninstalls the application shortly after or way later but the dependencies stay unused installed on the system. Commandline UI (zypper) only. References: https://bugzilla.novell.com/show_bug.cgi?id=166132 Discussion: #1: Jiri Srain (jsrain) (2007-06-05 13:46:00) Schubi, is there any possibility to make solver tell which packages are orphanized? It would be interesting especially if the packages which are marked for deletion were considered as non-installed (eg. if foo- devel is installed but marked for deletion and nothing else requires foo, then foo is orphanized). #2: Stefan Schubert (schubi2) (2007-06-06 11:04:04) (reply to #1) Currently not cause the solver has no information about who (user, package,...) has triggered the installation of a package. If we are storing this information it would be possible for solver to remove these kind of packages too. It is not simple but doable. By the way, we will have to store this kind of information in the future. E.g. we need to save the "keep state by user" in a database in order to regard this state in future solver runs. #3: Jiri Srain (jsrain) (2007-06-06 14:25:07) (reply to #2) Looks like a missunderstanding. Basically every package wihch is not required/recommended/suggested or doesn't enhance anything that is installed and not marked for deletion is IMO considered to be orphanized. If user eg. wants to remove a pattern including all its packages (which are not required by something else), solver providing this kind of information would help a lot (and I don't think that we would need any other information to be stored. #4: Stefan Schubert (schubi2) (2007-06-06 15:33:44) (reply to #3) I do not think so. What does "orphanized" mean ? Let me take your example from comment #1. foo should be deleted too if the user delete foo-devel and foo has been installed due the requirement of foo-devel. BUT the user will kill us if we are deleting foo although the user has installed foo explicit sometime ago in a seperate installation workflow. So this information ( The USER has installed foo) will be currently not saved and is needed here to decide if foo has to be deleted or not. #5: Stefan Schubert (schubi2) (2007-06-06 15:39:47) (reply to #3) Lets take your example concerning the erasing of patterns. That is much more complex. I have already described the problem here: http://en.opensuse.org/Libzypp/Solver#Known_Problems " Proper behaviour of erasing patterns" There are already some bugzilla entries: Bug 274283 - Delete iFolder from YaST makes eDirectory Delete mandatory Bug 238250 - YaST does not upgrade an Add-on Product #6: Jiri Srain (jsrain) (2007-06-08 16:46:32) See also https://bugzilla.novell.com/show_bug.cgi?id=166132 This is another use case for the same solver functionality #8: Federico Lucifredi (flucifredi) (2008-06-12 20:46:17) this should be commandline-only, definitely an advanced-user option. #9: Federico Lucifredi (flucifredi) (2008-06-12 20:47:28) cut from description: See Bug 140346 #10: Duncan Mac-Vicar (dmacvicar) (2008-11-03 11:24:53) As discussed in Prague, this could be done using the package history once we have a reader. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=300758

1 0

[openFate 300754] Key Management for YAST / Zypper / Updaters
by fate_noreply＠suse.de 16 Jan '09

16 Jan '09

Feature changed by: Duncan Mac-Vicar (dmacvicar) Feature #300754, revision 55 Title: Key Management for YAST / Zypper / Updaters openSUSE-10.2: Rejected by Thorsten Kukuk <kukuk(a)novell.com> reject date: 2006-10-17 10:57:07 reject reason: Yes, we need better GPG key management, but not as additional module, but integrated in the parts who add installation sources. Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Jiri Srain <jsrain(a)novell.com> reject date: 2008-04-15 10:34:32 reject reason: Missing input from security team. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-07-31 15:24:49 reject reason: Out of resources. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Marcus Meissner (msmeissn) Interested: Andreas Jaeger (a_jaeger) Interested: Guy Lunardi (glunardi) Interested: Karl Eichwalder (keichwa) Interested: Matthias Eckermann (mge1512) Interested: Security Team (secteam) Interested: Thorsten Kukuk (kukuk) Partner organization: openSUSE.org Description: On GPG key import (when adding package repositories) we currently just show the key id and the fingerprint of the key. We need better key management and this could be done in a new YAST Module, which could do things like: * Key import from disk or from network (keyservers preset/configurable). * On key import, show fingerprints and allow to browse signatures (also showing which are already trusted or not), and expiry dates. * Key removal / remove trust possible. Design should be worked on together with the security team. References: https://bugzilla.novell.com/show_bug.cgi?id=186764 https://bugzilla.novell.com/show_bug.cgi?id=115485 Documentation Impact: Needs Documentation in Admin guide. Discussion: #1: Edith Parzefall (emapedl) (2006-09-05 12:02:06) Jiri, do you have some one for the YaST module? #2: Edith Parzefall (emapedl) (2006-09-05 12:02:48) Adding Duncan as technical contact. #8: Ladislav Slezak (lslezak) (2008-01-17 15:17:07) The GPG key manager is part of the repository manager, submitted in yast2-packager-2.16.15 The current key manager displays a table with all trusted keys and user can do: * import a GPG key from a file * remove a GPG key from the trusted keyring * display details about a key (fingerprint, creation and expiration dates) It doesn't support/display untrusted keys because they do not have a persistent storage (the trusted keys are stored in the RPM DB), all untrusted keys are lost at exit, so it doesn't make sense to work with them. The popup displayed when importing a GPG key now displays creation and expiration dates. If the key is expired there is a warning message. Is that functionality sufficient or do we need to be able to fetch a key from a keyserver? Do we really need to browse all signauters of the key? #9: Marcus Meissner (msmeissn) (2008-02-25 17:50:02) (reply to #8) Sorry, I did not yet have the time to review this (and install Alpha2+)... Will get back to you as soon as I find testing time. #10: Marcus Meissner (msmeissn) (2008-03-19 17:37:29) (reply to #8) I just now had a look at Alpha3. It is not sufficient I am afraid. On adding a new repositories, just before this import dialog, the list of signatures should really be shown. What I had in mind: - in the "import key" dialog, offer the list of signatures. - show GPG signatures from keys that we know as "good" somehow. -> signatures for keys already in RPMDB -> [locally trusted key] -> signatures for SUSE specific ones (from root? rpm? keyring= -> [SUSE trusted key] -> others [untrusted key] Its quite more than there currently is. Hmm #15: Federico Lucifredi (flucifredi) (2008-06-12 17:16:47) Marcus, please let me know whyat above and beyond the 11.0 status is desired, if any. #16: Marcus Meissner (msmeissn) (2008-06-13 22:43:12) (reply to #15) Partially / Half done. We have not found a fully good solution, this needs direct communication with the YAST2 developer and the security team, perhaps during the YAST2 workshop. And we also should review of how the current code is used and accepted by users in 11.0. So we will revisit for 11.1. #17: Federico Lucifredi (flucifredi) (2008-06-13 18:06:48) (reply to #16) okie, giving it an Important for now then. #21: Ludwig Nussel (lnussel) (2008-07-18 10:13:32) please reconsider priority of this feature with the current hype about package management security in mind. #25: Duncan Mac-Vicar (dmacvicar) (2009-01-08 16:36:49) Basic key management is already there. Federico, what is Important for PM here? which concrete functionality? #26: Federico Lucifredi (flucifredi) (2009-01-08 14:48:09) (reply to #25) From my point of view, I would like trust to be terminated when removing a repo from the subscribed list (i.e. also removing the keys previously approved). Kurt was at the origin of this feature, we may also want to hear from him on the current state (adding needinfo). #27: Duncan Mac-Vicar (dmacvicar) (2009-01-09 17:51:27) (reply to #26) Ok, some input would be needed: * What happens if the repo was originally signed with one key, which was trusted, and then the key changed, this one was trusted too? * Multiple repos signed with the same key? I feel the approach is some kind of reference count? But that means that if the user removes all repo, he will even get rid of the build key. #28: Kurt Garloff (garloff) (2009-01-09 19:11:01) (reply to #27) When judging the trustworthiness of a new key, the signatures of a key should be displayed -- limiting the display to signatures with keys that we already trust would be OK, from my POV. An option to automatically trust a new key if it's signed with an already trusted key would also be a good thing to have, this way allowing to use a hierarchical CA model of trust if the user wants so. It could be a global flag, but better would be per key: "Trust every key that has been signed by this key." Actually, I think we should have such trust chains -- there could be a SUSE master key that's trusted by default and then packages get signed with different keys, depending on where we build them (Provo, abuild, ...). There could be a master key for all OBS repos (though I personally would not enable "trust all keys signed by this"). (Note: I know that full trust chains would walk a signature chain and check recursively ... we can do that as well, but it's a bit more complicated with GPG. But as RPMs are signed with GPG keys, I think it's not a good idea to mix that with openssl (X.509) certificates ...) Duncan -- I would indeed think that the ref counting that you mention is the way we would want to handle this. When you have a key that's not used by any repo any longer, the admin should be offered to remove it from the list of trusted keys (and I would think we should default to remove). Same for keys that have expired. I think our security folks should drive the requirements here -- and someone needs to complement their view from a usability perspective. (A security feature is useless if everybody switches it off because it's an annoyance ;-)) Note: We've had 2 years of time to sort this :-( + #29: Duncan Mac-Vicar (dmacvicar) (2009-01-16 15:19:30) + Repository keys/signatures meeting 15.01.2009 + present: dmacvicar, draht, lnussel, meissner + How current model works: + http://en.opensuse.org/Libzypp/Metadata_Signature + How to solve? + 1) amount of key imports and confirm dialogs (ie: NVIDIA) (less dialogs + the better + 2) Usability of the dialog. Nobody reads the fingerprint and therefore + dialog is useless. + 3) feature #300754 requirements + Item 3 has the following requirements: + 1) transitive trust + 2) removal of keys + Feasible solutions for 11.1: + * Would be solved by 3.1) allowing SUSE to sign NVIDIA's key and + utomatically trust with 1 level. + * Show the fingerprint in a easy to compare way (*) + Making fingerprints easy to compare: + * randomart (openssh's key_fingerprint_randomart ) + * "Hash Visualization: a New Technique to improve Real-World Security", + Perrig A. and Song D., 1999, International Workshop on Cryptographic + Techniques and E-Commerce (CrypTEC '99) sparrow.ece.cmu. + edu/~adrian/projects/validation/validation.pdf + * bubblebabble / diceware? (ie: `1234567890' is`xesef-disof-gytuf-katof- + movif-baxux' ) + * We need to tell when the key changed explicitly. + * 3.1 will be used to solve 1). 3.2 as described by PM has no benefit + from security point of view, and manual management of the keys is + already possible. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=300754

1 0

[openFate 300758] Show orphaned packages
by fate_noreply＠suse.de 16 Jan '09

16 Jan '09

Feature changed by: Santiago Hirschfeld (jsantiagoh) Feature #300758, revision 36 Title: Show orphaned packages openSUSE-10.2: Rejected by Thorsten Kukuk <kukuk(a)novell.com> reject date: 2006-08-02 11:31:19 reject reason: For SL10.2 we have to get libzypp really stable and fast before we add new features. Priority Requester: Important openSUSE-10.3: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2007-07-17 17:03:57 reject reason: Postponing. Priority Requester: Important Projectmanager: Desirable openSUSE-11.0: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2007-11-21 12:16:20 reject reason: Out of scope for 11.0 Priority Requester: Important openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-07-07 13:34:02 reject reason: Postponing, needs underlaying infrastructure to be fixed first. Priority Requester: Important openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Stephan Binner (beineri) Interested: Andreas Jaeger (a_jaeger) Interested: Ján Kupec (jkupec) Interested: Matthias Eckermann (mge1512) + Interested: Santiago Hirschfeld (jsantiagoh) Interested: Vincent Untz (vuntz) Partner organization: openSUSE.org Description: The package manager should learn to show orphanized packages (packages which are not required by other packages and are not in wanted selections) and allow to deinstall them like the popular debfoster/deborphan tools. A typical use case: user installs an application which pulls in some dependencies to test it, uninstalls the application shortly after or way later but the dependencies stay unused installed on the system. Commandline UI (zypper) only. References: https://bugzilla.novell.com/show_bug.cgi?id=166132 Discussion: #1: Jiri Srain (jsrain) (2007-06-05 13:46:00) Schubi, is there any possibility to make solver tell which packages are orphanized? It would be interesting especially if the packages which are marked for deletion were considered as non-installed (eg. if foo- devel is installed but marked for deletion and nothing else requires foo, then foo is orphanized). #2: Stefan Schubert (schubi2) (2007-06-06 11:04:04) (reply to #1) Currently not cause the solver has no information about who (user, package,...) has triggered the installation of a package. If we are storing this information it would be possible for solver to remove these kind of packages too. It is not simple but doable. By the way, we will have to store this kind of information in the future. E.g. we need to save the "keep state by user" in a database in order to regard this state in future solver runs. #3: Jiri Srain (jsrain) (2007-06-06 14:25:07) (reply to #2) Looks like a missunderstanding. Basically every package wihch is not required/recommended/suggested or doesn't enhance anything that is installed and not marked for deletion is IMO considered to be orphanized. If user eg. wants to remove a pattern including all its packages (which are not required by something else), solver providing this kind of information would help a lot (and I don't think that we would need any other information to be stored. #4: Stefan Schubert (schubi2) (2007-06-06 15:33:44) (reply to #3) I do not think so. What does "orphanized" mean ? Let me take your example from comment #1. foo should be deleted too if the user delete foo-devel and foo has been installed due the requirement of foo-devel. BUT the user will kill us if we are deleting foo although the user has installed foo explicit sometime ago in a seperate installation workflow. So this information ( The USER has installed foo) will be currently not saved and is needed here to decide if foo has to be deleted or not. #5: Stefan Schubert (schubi2) (2007-06-06 15:39:47) (reply to #3) Lets take your example concerning the erasing of patterns. That is much more complex. I have already described the problem here: http://en.opensuse.org/Libzypp/Solver#Known_Problems " Proper behaviour of erasing patterns" There are already some bugzilla entries: Bug 274283 - Delete iFolder from YaST makes eDirectory Delete mandatory Bug 238250 - YaST does not upgrade an Add-on Product #6: Jiri Srain (jsrain) (2007-06-08 16:46:32) See also https://bugzilla.novell.com/show_bug.cgi?id=166132 This is another use case for the same solver functionality #8: Federico Lucifredi (flucifredi) (2008-06-12 20:46:17) this should be commandline-only, definitely an advanced-user option. #9: Federico Lucifredi (flucifredi) (2008-06-12 20:47:28) cut from description: See Bug 140346 #10: Duncan Mac-Vicar (dmacvicar) (2008-11-03 11:24:53) As discussed in Prague, this could be done using the package history once we have a reader. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=300758

1 0

[openFate 305634] Debian-like dist-upgrade live system full version upgrade
by fate_noreply＠suse.de 16 Jan '09

16 Jan '09

Feature changed by: Francis Giannaros (apokryphos) Feature #305634, revision 18 Title: Debian-like dist-upgrade live system full version upgrade openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Federico Lucifredi (flucifredi) Interested: Andre Duffeck (aduffeck) + Interested: Francis Giannaros (apokryphos) Interested: Guy Lunardi (glunardi) Interested: Joe Brockmeier (jbrockmeier) Interested: JP Rosevear (jproseve) Interested: Klaus Kämpf (kwk) Interested: Matthias Eckermann (mge1512) Interested: Stefan Behlert (sbehlert) Interested: Stephan Binner (beineri) Interested: Stephan Kulow (coolo) Interested: Thorsten Kukuk (kukuk) Partner organization: openSUSE.org Description: With the 11.2 cycle, we want to offer users the ability to perform a live system upgrade in the manner of Debian's dist-upgrade. For the purpose of this cycle, we want to support dist-upgrade from the previous version (11.1) only, as this is a sufficiently complicated problem as is. From the user's view, the difference is between being able to update the system incrementally within the given version or service pack running, to being ble to migrate with a system command ("zypper dup" or similar) to a higher version altogether. In the Debian experience, the set of base distributions is not necessarily limited, but it has been Ubuntu's practice to define what starting points other than "release n-1" are allowed (for instance, all LTS versions are purported to be able to "apt dist-upgrade" to the top of the line, although I have heard of problems trying to jump two years - 6.06->8.10 - in a fell swoop in this manner :-). In the openSUSE scope, we should aim to be able to "dup" between incremental versions, starting from 11.1 to 11.2, and later 11.x to 12.0. Business case (Partner benefit): openSUSE.org: With the introduction of the Zypper stack to SLE, we finally reached the state of a featureful (which YOU was not) and fast, reliable (which ZLM was not) update stack in the platform. For enterprise use, some tweaks are still desirable (changelogs, rollback, ...) which we are looking at, as well as improvements on the Enterprise management front, which we are working on with our SRM colleagues. The only really significant competitive feature we are missing at this point is the Debian/Ubuntu dist-upgrade functionality, which has a powerful psychological impact at the Enterprise level and a much more tangible impact at the small user / single user level: many with no IT department do use Ubuntu these days on the basis that "chasing" Fedora and openSUSE along the six-month upgrade cycle is too much for them, and feel they can save time on Ubuntu with the combination of dist- upgrade and the longer LTS cycle. The rationale for pursuing this is to revoke the special status of coolness this functionality gives Ubuntu, and to terminate the negative influence that may have on our SLE sales (from the expert's personal opinion, the preference then easily spills into purchasing). Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-07 20:42:15) This is the #1 feature in the systems management scope for 11.2 - I have no doubt it will be fun :-) #4: Klaus Kämpf (kwk) (2009-01-09 11:32:53) Passing to mls for technical evaluation (solver + autobuild) #5: Michael Schröder (mlschroe) (2009-01-09 12:48:10) Any hint on what features are currently missing? #6: Klaus Kämpf (kwk) (2009-01-09 13:30:57) (reply to #5) From the top of my head: How to handle * Library ABI changes (e.g. major gcc/g++ upgrades) ? * Core package changes (e.g. devs.rpm to udev) ? * Kernel changes (if application/deamons need a specific kernel abi, dbus comes into mind) ? * Failure handling (network breakdown, package update errors, ...) ? * Booting of the new kernel ? #7: Michael Schröder (mlschroe) (2009-01-09 14:45:09) (reply to #6) And debian does this in some way? -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305634

1 0

[openFate 302047] Integrated package searching for YaST and build service
by fate_noreply＠suse.de 16 Jan '09

16 Jan '09

Feature changed by: Francis Giannaros (apokryphos) Feature #302047, revision 32 Title: Integrated package searching for YaST and build service openSUSE-10.3: Rejected by Andreas Jaeger <aj(a)novell.com> reject date: 2007-10-05 14:30:28 reject reason: still open partly - postpone the rest. Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Michael Loeffler <michl(a)novell.com> reject date: 2008-06-10 14:01:45 reject reason: not done for 11.0 Priority Requester: Important Projectmanager: Important openSUSE-11.1: Rejected by Adrian Schröter <adrian(a)novell.com> reject date: 2008-09-04 18:17:10 reject reason: No time for it, but we have the one-click installation supported from web interface. Priority Requester: Important Projectmanager: Desirable Requested by: Duncan Mac-Vicar (dmacvicar) Interested: Andreas Jaeger (a_jaeger) Interested: Christoph Thiel (cthiel1) Interested: Ciaran Farrell (babelworx) Interested: daniel bornkessel (dbornkessel) Interested: Duncan Mac-Vicar (dmacvicar) + Interested: Francis Giannaros (apokryphos) Interested: Juergen Weigert (jnweiger) Interested: Stanislav Visnovsky (visnov) Partner organization: openSUSE.org Description: You perhaps remember the hacks Benjamin did to support "click and install" packages (similar to Click'n run) [1] Benjamin has another article in his blog that is worth to read. He has been providing a wepage to search packages from repositories like packman and build service. Now he presents an architecture to desentralize the system, using web services an indexers, and he shows working prototypes of YaST modules for searching, and others like web and irc-bot clients http://blogs.warwick.ac.uk/bweber/entry/package_search_developments/ I hope we can provide a strategy and roadmap to integrate these cool ideas and _code_. [1]: http://blogs.warwick.ac.uk/bweber/entry/next_generation_package/ Discussion: #1: Juergen Weigert (jnweiger) (2007-05-03 15:29:13) see also 300898 For 10.3 the installer should be able to make use of an external list of repositories. I suggest to host such a list at http://packages.opensuse-community.org/ together with the search engine, which is already there. #3: Klaas Freitag (kfreitag) (2007-07-12 10:46:54) Implementation on openSUSE BS already started, Adrian knows the details. #4: Adrian Schröter (adriansuse) (2007-07-12 11:30:04) We work on two approaches atm: * YaST will support (thanks to mvidner) additional repository offers during installation. The list gets hosted on our servers, the open question is how to maintain this list. * The build service End-User interface will offer .ymp files based on pattern submissions for easy installation. #5: Stanislav Visnovsky (visnov) (2007-07-30 20:13:09) (reply to #4) Adrian, please, drive this. The feature for YaST should be done now (let me know if anything is missing). #6: Michael Loeffler (sprudel24) (2007-11-22 11:26:30) This sounds like very useful. And it might be possible the community (in this case Benji) helps implementing this. #7: Andreas Jaeger (a_jaeger) (2008-06-06 10:56:28) Apparently not done - please reject and postpone for 11.1. #9: Adrian Schröter (adriansuse) (2008-06-18 17:08:16) This is something what we should bind to the new upcomming software portal. The software portal will be the End-User interface for searcing and installing software and replace http://software.opensuse.org/search . However it is still in development and not yet set up. Therefore I am unsure if this can happen in time for 11.1. On the other side, the 1-click-installation and integration into the web interface is done since quite some time. The user can use the cool technologies from Benjamin since 10.3. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=302047

1 0

[openFate 303532] Reduce size of updates for openSUSE Factory
by fate_noreply＠suse.de 16 Jan '09

16 Jan '09

Feature changed by: Stephan Kulow (coolo) Feature #303532, revision 15 Title: Reduce size of updates for openSUSE Factory Buildservice: Evaluation Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Stephan Kulow <coolo(a)novell.com> reject date: 2008-06-06 09:06:29 reject reason: not really attached to a specific openSUSE version Priority Requester: Important Projectmanager: Important openSUSE-11.1: Rejected by Adrian Schröter <adrian(a)novell.com> reject date: 2008-11-06 16:10:03 reject reason: This is a build service feature, but no distribution feature. Priority Requester: Important Projectmanager: Important Requested by: Michael Loeffler (sprudel24) Interested: Duncan Mac-Vicar (dmacvicar) Interested: Gerald Pfeifer (geraldpfeifer) Interested: Klaas Freitag (kfreitag) Interested: Lukas Lipavsky (llipavsky) Interested: Michal Marek (michal-m) Interested: Peter Poeml (poeml) Interested: Ruediger Oertel (oertel) Interested: Stephan Kulow (coolo) Interested: Vincent Untz (vuntz) Description: Each update currently is around 2GB which is already much for broadband bandwith. For user with less bandwith it's by and large impossible to use Factory. Goal is to reduce size of updates and stay with frequent updates to offer latest software to the user. As we want more people using Factory it's usage needs to be conveniant. Discussion: #1: Stephan Kulow (coolo) (2008-03-27 16:48:43) According to discussions with Rudi and mls, the delta setup on dist need to be changed to also contain the rpm header and the deltas need to be indexed in a way that zypp will see them. So we can still use drpmsync for internal distribution and put the deltas only in instsource for mirrors. #2: Duncan Mac-Vicar (dmacvicar) (2008-04-22 13:28:56) This will happen automatically once the remaining parts of libzypp deltarpm handling are finished. We only need to agree on the format. I will propose something today. #3: Duncan Mac-Vicar (dmacvicar) (2008-05-26 17:09:31) ZYpp side is done. The only thing that needs to be done is to generate the deltarpm metadata in factory. I will post link to documentation and examples shortly. #4: Gerald Pfeifer (geraldpfeifer) (2009-01-03 14:54:00) Opening this up for openSUSE.org. + #5: Stephan Kulow (coolo) (2009-01-16 08:24:42) + ok, we discussed this a bit further. We plan to throw away builds that + are equal to the previous build and publish deltas generated by the + build clients if they are not equal. + If a build is equal is to be defined, for now it's a shell script that + checks various properties - and works acceptable for now. + I rebuild a good portion of 11.1 without further changes and get 7345 + binary rpms (including all subpackages). 5666 are considered equal by + my current script (based on work by Michael Matz). + And many of other packages are possible to fix, so they are equal too. + So this gives for uneffected rebuilds a huge reduction of updates. + The kernels and kmps are currently seen as !equal after an uneffected + rebuild as they put the %release (rebuild counter) in many places. Not + sure how much the script should work around such cases. + But even for those the download size would reduce: kernel-default.i586 + (with base and extra): 25.7MB to download deltas of it: 6.7MB (I think + the kernel puts a lot of "rebuild on" info in the code) -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303532

1 0

[openFate 302047] Integrated package searching for YaST and build service
by fate_noreply＠suse.de 15 Jan '09

15 Jan '09

Feature changed by: Juergen Weigert (jnweiger) Feature #302047, revision 31 Title: Integrated package searching for YaST and build service openSUSE-10.3: Rejected by Andreas Jaeger <aj(a)novell.com> reject date: 2007-10-05 14:30:28 reject reason: still open partly - postpone the rest. Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Michael Loeffler <michl(a)novell.com> reject date: 2008-06-10 14:01:45 reject reason: not done for 11.0 Priority Requester: Important Projectmanager: Important openSUSE-11.1: Rejected by Adrian Schröter <adrian(a)novell.com> reject date: 2008-09-04 18:17:10 reject reason: No time for it, but we have the one-click installation supported from web interface. Priority Requester: Important Projectmanager: Desirable Requested by: Duncan Mac-Vicar (dmacvicar) Interested: Andreas Jaeger (a_jaeger) Interested: Christoph Thiel (cthiel1) Interested: Ciaran Farrell (babelworx) Interested: daniel bornkessel (dbornkessel) Interested: Duncan Mac-Vicar (dmacvicar) + Interested: Juergen Weigert (jnweiger) Interested: Stanislav Visnovsky (visnov) Description: You perhaps remember the hacks Benjamin did to support "click and install" packages (similar to Click'n run) [1] Benjamin has another article in his blog that is worth to read. He has been providing a wepage to search packages from repositories like packman and build service. Now he presents an architecture to desentralize the system, using web services an indexers, and he shows working prototypes of YaST modules for searching, and others like web and irc-bot clients http://blogs.warwick.ac.uk/bweber/entry/package_search_developments/ I hope we can provide a strategy and roadmap to integrate these cool ideas and _code_. [1]: http://blogs.warwick.ac.uk/bweber/entry/next_generation_package/ Discussion: #1: Juergen Weigert (jnweiger) (2007-05-03 15:29:13) see also 300898 For 10.3 the installer should be able to make use of an external list of repositories. I suggest to host such a list at http://packages.opensuse-community.org/ together with the search engine, which is already there. #3: Klaas Freitag (kfreitag) (2007-07-12 10:46:54) Implementation on openSUSE BS already started, Adrian knows the details. #4: Adrian Schröter (adriansuse) (2007-07-12 11:30:04) We work on two approaches atm: * YaST will support (thanks to mvidner) additional repository offers during installation. The list gets hosted on our servers, the open question is how to maintain this list. * The build service End-User interface will offer .ymp files based on pattern submissions for easy installation. #5: Stanislav Visnovsky (visnov) (2007-07-30 20:13:09) (reply to #4) Adrian, please, drive this. The feature for YaST should be done now (let me know if anything is missing). #6: Michael Loeffler (sprudel24) (2007-11-22 11:26:30) This sounds like very useful. And it might be possible the community (in this case Benji) helps implementing this. #7: Andreas Jaeger (a_jaeger) (2008-06-06 10:56:28) Apparently not done - please reject and postpone for 11.1. #9: Adrian Schröter (adriansuse) (2008-06-18 17:08:16) This is something what we should bind to the new upcomming software portal. The software portal will be the End-User interface for searcing and installing software and replace http://software.opensuse.org/search . However it is still in development and not yet set up. Therefore I am unsure if this can happen in time for 11.1. On the other side, the 1-click-installation and integration into the web interface is done since quite some time. The user can use the cool technologies from Benjamin since 10.3. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=302047

1 0

[openFate 305634] Debian-like dist-upgrade live system full version upgrade
by fate_noreply＠suse.de 15 Jan '09

15 Jan '09

Feature changed by: Stanislav Visnovsky <visnov(a)novell.com> Feature #305634, revision 17 Title: Debian-like dist-upgrade live system full version upgrade openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Federico Lucifredi (flucifredi) Interested: Andre Duffeck (aduffeck) Interested: Guy Lunardi (glunardi) Interested: Joe Brockmeier (jbrockmeier) Interested: JP Rosevear (jproseve) Interested: Klaus Kämpf (kwk) Interested: Matthias Eckermann (mge1512) Interested: Stefan Behlert (sbehlert) Interested: Stephan Binner (beineri) + Interested: Stephan Kulow (coolo) Interested: Thorsten Kukuk (kukuk) Description: With the 11.2 cycle, we want to offer users the ability to perform a live system upgrade in the manner of Debian's dist-upgrade. For the purpose of this cycle, we want to support dist-upgrade from the previous version (11.1) only, as this is a sufficiently complicated problem as is. From the user's view, the difference is between being able to update the system incrementally within the given version or service pack running, to being ble to migrate with a system command ("zypper dup" or similar) to a higher version altogether. In the Debian experience, the set of base distributions is not necessarily limited, but it has been Ubuntu's practice to define what starting points other than "release n-1" are allowed (for instance, all LTS versions are purported to be able to "apt dist-upgrade" to the top of the line, although I have heard of problems trying to jump two years - 6.06->8.10 - in a fell swoop in this manner :-). In the openSUSE scope, we should aim to be able to "dup" between incremental versions, starting from 11.1 to 11.2, and later 11.x to 12.0. Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-07 20:42:15) This is the #1 feature in the systems management scope for 11.2 - I have no doubt it will be fun :-) #4: Klaus Kämpf (kwk) (2009-01-09 11:32:53) Passing to mls for technical evaluation (solver + autobuild) #5: Michael Schröder (mlschroe) (2009-01-09 12:48:10) Any hint on what features are currently missing? #6: Klaus Kämpf (kwk) (2009-01-09 13:30:57) (reply to #5) From the top of my head: How to handle * Library ABI changes (e.g. major gcc/g++ upgrades) ? * Core package changes (e.g. devs.rpm to udev) ? * Kernel changes (if application/deamons need a specific kernel abi, dbus comes into mind) ? * Failure handling (network breakdown, package update errors, ...) ? * Booting of the new kernel ? #7: Michael Schröder (mlschroe) (2009-01-09 14:45:09) (reply to #6) And debian does this in some way? -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305634

1 0