April 2011 - openSUSE Features - openSUSE Mailing Lists

[openFATE 305715] Package event framework
by fate_noreply＠suse.de 01 Apr '11

01 Apr '11

Feature changed by: Stanislav Visnovsky (visnov) Feature #305715, revision 17 Title: Package event framework openSUSE-11.2: Rejected by Andreas Jaeger (a_jaeger) reject date: 2009-06-09 14:44:19 reject reason: We're not going to manage to do this for 11.2. If rpm gets all the changes, we can incorporate this later. Priority Requester: Desirable - Info Provider: (Novell) Requested by: Andreas Gruenbacher (agruen) Product Manager: (Novell) Product Manager: (Novell) Project Manager: (Novell) Technical Contact: (Novell) Technical Contact: (Novell) Partner organization: openSUSE.org Description: The installation, upgrade, or removal of several packages triggers actions such as running ldconfig, rebuilding the initrd, or similar. Those actions are not specific to the package at hand, but either global with a system-wide effect (such as running ldconfig), or they affect a group of packages (such as all kernel (sub-)packages of a specific version, including all KMPs affecting it). Those actions need to be run eventually (with order restrictions relative to other package installs, upgrades, or removals), but running them again and again for each package is wasteful. (Example: with the kernel packages split into kernel-$flavor-base, kernel-$flavor, and kernel-$flavor-extra in CODE11, we currently run mkinitrd out of the %post script of each package. We don't know which of those packages will be installed, and when generating the initrd is supposed to succeed. This both wastes time, and we also cannot tell transient from permanent failures.) In former days, SuSEconfig was used for some of those tasks, but it turned into a major nightmare (perhaps due to its design). It would be nice if we could come up with a framework in which packages can trigger events and define which actions they need to be run, and rpm will then perform those actions in an appropriate order, avoiding repeating the same action unnecessarily. (The dependencies between actions and package installs/upgrades/removals are somewhat complex, but I think they are manageable.) Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-23 18:09:34) This is desirable only as it happens within RPM's framework (or if the additions are "candy" that does not affect the actual result). This includes upstreaming. I do not want to comment besides the RPM requirement until Engineering determines how (and if) to proceed. There are too many factors involved. Stano, Needinfo me back when you guys have a settled position or decide to postpone this one given the other priorities. #2: Klaus Kämpf (kwk) (2009-01-29 12:45:22) Actually, there is probably litte engineering can do or decide here imho. It very much depends on PMs long-term strategy for RPM. There are currently two options * One is to stay with rpm 4.x and keep the status quo. * The other is to move up to rpm5 and try to influence its development. Upstream implementation of the feature request can only happen within rpm5. Adopting rpm5 for the distribution has several prerequisites: * Investment into rpm5 development. * Getting more distributions to adopt rpm5. * Influencing Linux Standards Base to accept rpm5. Given recent comments from RedHat/Fedora, widespread rpm5 adoption looks rather unlikely. #3: Michael Schröder (mlschroe) (2009-01-29 12:50:19) (reply to #2) That sounds like rpm-4 doesn't get new features at all, which is simply not true. Actually I think it's probably easier to get new features into rpm-4, because it's very hard to convince Jeff of something he doesn't like, whereas Panu is more open. #4: Klaus Kämpf (kwk) (2009-01-29 13:22:30) (reply to #3) Now thats good to know. But this probably still needs a significant investment (and a fair bit of persuasion) into rpm4, I guess. #5: Casper Clemence (maninalift) (2009-02-28 15:05:35) I don't know about the issue of how the installer works but from a user perspective the handling of multiple kernel flavours could certainly be better. At the moment a symbolic link is automatically created at /boot/vmlinuz pointing, rather arbitrarily IMO, to the most recently updated kernel. Also the grub menu is messed with in an inept sort of a way. If instead symbolic links were created for each kernel flavour there would be no need to change the grub menu except when new flavours were installed or others removed, thus preserving all of the users other boot settings. #6: Klaus Kämpf (kwk) (2009-09-22 12:35:25) The "rpm summit" which was held during the 2009 openSUSE conference brought us a big step forward here. We've now established a healthy relationship with 'rpm4 upstream' and thus will _not_ move to rpm5 anytime soon. Rpm4 will add 'file triggers' in a future version, makeing it possible to e.g. run 'ldconfig' if a library file was installed, updated or removed. A couple of other use cases come into mind for this. --- I'd recommend to close this feature request for now and wait for rpm4 upstream to come up with a solution. -- openSUSE Feature: https://features.opensuse.org/305715

1 0

[openFate 305587] Yast template for theming
by fate_noreply＠suse.de 01 Apr '11

01 Apr '11

Feature added by: Jakub Steiner <jimmac(a)novell.com> Feature #305587, revision 1, last change by Title: Yast template for theming openSUSE-11.2: New Priority Requester: Important Requested by: Jim McEldowney <jimmac(a)erie.net> Partner organization: openSUSE.org Description: To be able to skin the Yast installer properly, I would welcome the existence of a YCP template to include all of the widgets included in the actual installer. Business case (Partner benefit): openSUSE.org: Without such a testbed it's extremely hard and error prone to create new styling. In some cases it's impossible to see the implications of a style change until after it has been submitted to build and new distribution snapshot released. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305587

1 6

[New: openFATE 311865] openFATE Demo 16-March 2011
by fate_noreply＠suse.de 01 Apr '11

01 Apr '11

Feature added by: Andreas Jaeger (a_jaeger) Feature #311865, revision 1 Title: openFATE Demo 16-March 2011 openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Andreas Jaeger (a_jaeger) Partner organization: openSUSE.org Description: Just the description. Use Case: Use case for demo (http://www.novell.com) -- openSUSE Feature: https://features.opensuse.org/311865

1 5

[openFATE 305877] Popularity contest
by fate_noreply＠suse.de 01 Apr '11

01 Apr '11

Feature changed by: Rajko Matovic (rajko_m) Feature #305877, revision 38 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 + openSUSE Distribution: Unconfirmed + 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