August 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 305299] Port kio_fuse to KDE4
by fate_noreply＠suse.de 06 Aug '09

06 Aug '09

Feature changed by: Ralf Petter (petter_r) Feature #305299, revision 8 Title: Port kio_fuse to KDE4 openSUSE-11.2: Evaluation Priority Requester: Important Projectmanager: Desirable Requested by: JP Rosevear (jproseve) Description: Enable kio mounted file systems to be exposed via fuse by getting kio_fuse to work on KDE4. Relations: - Integrate fuse based permanent mounting (feature/id: 300613) Discussion: #1: Michael Löffler (michl19) (2009-06-05 14:34:38) JP, what would be the benefit? Please add to the description. #2: Todd R (theblackcat) (2009-07-01 23:31:24) I think the main benefit would be that applications that do not support kio (most non-KDE apps) would still be able to see the files. Presently this is not possible. + #3: Ralf Petter (petter_r) (2009-08-06 11:22:36) + Yes that will be really important. Simply try to open an openoffice + document from an samba server in dolphin and openoffice opens, but no + file. This should really work out of the box. -- openSUSE Feature: https://features.opensuse.org/305299

1 0

[openFATE 305326] 5 Second Boot
by fate_noreply＠suse.de 05 Aug '09

05 Aug '09

Feature changed by: Ralph Ulrich (ulenrich) Feature #305326, revision 17 Title: 5 Second Boot openSUSE-11.2: Rejected by Stephan Kulow (coolo) reject date: 2009-02-09 15:47:52 reject reason: Sorry to be harsh, but this feature can't be implemented as asked for. Priority Requester: Mandatory Requested by: Jared Allen (jpallen) Partner organization: openSUSE.org Description: The amount of time required to boot up needs to be reduced drastically. I suggest we consider the work being done in this article: http://lwn.net/Articles/299483/ as our baseline and strive to make similar adjustments. Business case (Partner benefit): openSUSE.org: As we continue to get more involved in the Thin Client and UMPC markets, boot time becomes increasingly important. Intel's Moblin project is touting boot time as one of the significant features/advantages of their Moblin project. There are signs that other distros are following suit. We have at least one Thin Client partner that is requesting significant improvements in boot time in order to remain competitive. In fact, SLETC would have been included on more thin client hardware shipments to-date had we a faster boot time. Discussion: #1: Jared Allen (jpallen) (2008-10-06 17:03:30) I spoken with both AJ and Michael Meeks regarding this requirement. AJ suggested that include Coolo in the discussion since it will most definitely affect the distribution as a whole. #2: Stephan Kulow (coolo) (2009-01-20 15:18:14) similiar adjustments? Do you mean the "We had to do a lot of damage to X," part or the "use xfce" part? There is a limit on what you can do in a generic system and many of the low hanging fruits is already done. If you talk about getting a thin client to boot fast, then making transparent use of suspend & resume is the way to go IMO. Booting off cold hardware is problematic if you want more than xfce. There are about 100MB data to read for a pretty standard KDE session (and I assume GNOME is similiar) - on a pretty fragmented file system you get ~8MB/s netto - so just reading your files takes already 12s. Making preload dynamic on the blocks actually used is something that was discussed long, long ago, but the kernel still doesn't provide the infrastructure - so this is one of the TODOs, but possibly Intel got that ball rolling. Kernel drivers being quicker with probing would be another TODO, also listed in the article. Another urgent TODO is defragmentation because readahead helps only a little if the next update will scatter the files around your 1TB hard drive. #3: Jean-Daniel Dodin (jdd) (2009-02-15 10:28:27) may be this is plain stupid, forgive me if it is. The install time was dramatically reduced by the use of "images" of installs. Could it not be possible to build "images" of the installed system - that is to have all the necessary files on boot able to read at once. It's not exactly the same as suspend to disk, of like a suspend to disk with only the system. Most computers never change hardware and a new grub entry could be added: boot with new hardware + #4: Ralph Ulrich (ulenrich) (2009-08-05 23:14:17) + Squashfs could be utilized for that. It would be superior to preload as + it also could do the initrd thing. But every time a /bin/lib is updated + the whole squash-start-image needs to be updated also. Andthere it is + to make sure such an image is not fragmented on disk. -- openSUSE Feature: https://features.opensuse.org/305326

1 0

[openFATE 306411] Configuration files merge
by fate_noreply＠suse.de 05 Aug '09

05 Aug '09

Feature changed by: Michal Hrusecky (-miska-) Feature #306411, revision 16 Title: Configuration files merge openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Michal Hrusecky (-miska-) Description: If we want to make our distribution friendly even to advanced users, I think that we shouldn't touch users configuration files. Luckily this isn't problem as in spec file Ican state that this file is configuration and I don't want to replace it if user did some manual changes. Or I can say that I want to replace it and keep backup of original one. But what I'm missing is some tool to easily merge these files. In Gentoo there is etc-update (http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=3&chap=4#doc_…) or dispatch-conf (http://en.gentoo-wiki.com/wiki/Dispatch-conf) . I'll describe more precisely what feature I'm missing and why I think it's needed. Let's say that I've got some package and there was quite big change in package default configuration file which will affect most of the users. On the other hand users can have pretty complicated constructions in their configuration files and if they did something like that, it's quite possible that they don't need to update their configuration file. So it is needed to tell users that if they are experiencing problems it is most likely because they touched default configuration. I can take care of it manually, mention it in various README and such, but more easier way would be following. User installs some packages. At the end of zypper or yast installation there will be warning "You've got 42 configuration files to merge, please run etc-update/dispatch-conf/whatever". Then user will run some easy interactive tool which will state which configuration files can use some manual merging, it will allow user to see difference between them and let him choose which one he wants or let him merge them manually somehow. Same warning about unmerged configuration files should appear each time user installs something, no matter if this installation didn't add any conflict, until all conflicts are fixed. User will be warned about possible problems, hacker can play with it and keep his changes against distribution defaults and ordinary user will just click on "use distribution default for all" if he ever encounter such a problem (shouldn't happen as ordinary user wouldn't touch configuration files). I explained basic expected work flow, so now what I think should be supported: * detect configuration files, their conflicts and allow their merge - this shouldn't be a big problem as rpm already stores conflicting files as .rpmnew/.rpmold * we probably want to keep even old versions to support three way merge to achieve even better results * if we are already storing these configuration files, maybe we should let users to backup their own changes as well, add support for versioning these configuration files * warn user that he has conflicts in configuration files - will require a little bit yast/zypper integration * merging tool should support both console and graphical interface (maybe use yast as possible frontend) * support for various formats (expandable by plugins) - ordinary diff may not be the best tool for merging XML files or ini files * ordinary user who don't change anything shouldn't need to know about this tool Relations: - Debian-like dist-upgrade live system full version upgrade (feature/id: 305634) Discussion: #1: Michal Hrusecky (-miska-) (2009-06-02 09:49:38) I was thinking about this a little bit more and if we want to support some kind of versioning and we want to use plugins for getting differences, it may be a good idea to request that plugins will be capable not only of producing nice output of difference between configuration files, but it probably should be able to apply it (behave not only as a 'diff', but also as a 'patch'). And we can build some simple version control system on top of it. Advantages: * can handle non-plain text files better (via plugins) * we can implement feature to discard or merge several commits into one to save space/make commit log more readable * can handle nicelly even insane configuration files like sqlite database or compressed directory with configuration files or any other binary format Disadvantages: * probably worse handling of text files * another thing to maintain/possible source of bugs #2: Stephan Kulow (coolo) (2009-06-09 11:51:14) this sounds like a lot of work to do right and with little gain. We lived quite well for years without it and whatever tool you come up will create new problems, there won't be a perfect tool. Applications with very bizzare config format usually come with their own configuration update tool that can be called from %post So I would put very low imporance on this. #3: Andreas Jaeger (a_jaeger) (2009-06-09 14:20:14) (reply to #2) The question is what is really needed to do here. If we could take some scripts from Gentoo and those would work without changes - cool. If we would need to change each and every config file for this, I'm also for rejecting. So, for me it's not clear what the cost is. #4: Michal Hrusecky (-miska-) (2009-06-12 16:12:55) (reply to #3) Well, merging utility can be probably ported from Gentoo with few minor tweaks (although it would be console only utility) or it could be written from scratch (with possible features in mind). This shouldn't be a big problem (it will just take some time). In feature #305634 comment #19 there is even an example how to write such a simple utility. With current rpm workflow, I think there is no need for packages changes. Only thing that would need some adjustements for this feature to be fully functional is integration with yast/zypper so thay will print warning about possible conflicts. I wouldn't suggest to force people to solve, just printing that there are some and that they should solve them using this utility should be enough. So it will need just some hack/new feature in installation procedure - run a program and allow it to create some notification for user. This is probably related to feature #301175 (301175) #5: Michael Andres (mlandres) (2009-06-15 12:02:05) (reply to #3) Libzypp checks for changed configfiles, and if they differ the 'diff' output is written to /var/log/YaST2/ (I don't know if YaST still mails this to root). Notification is also /var/log/zypp/history, and AFAIK zypper displays some info as well. But it's not a big deal to have a more flexible consumer for this information. The easiest would be to check for the presence of a certain script (or a directory containing scripts), and if it exists invoke it with package names and configfiles as argument. Then you can install any handler you like. #6: Elmar Stellnberger ATK (estellnb) (2009-08-04 11:48:04) At Bug 506815, Comment #2 we have a more simple proposial simply notifying the user about changes in configuration files and selecting an appropriate .rpmnew/.rpmold strategy. This should be the first thing to be implemented in this regard before we can move on to fancier things like an interactive auto-diff&merge (https://bugzilla.novell.com/show_bug.cgi?id=506815#c2). I personally would not regard the gain as little since forgetting to re- create config files can be very tedious especially if you forget about it and especially if there are regular upgrades as for the buildservice repos. #7: Ralph Ulrich (ulenrich) (2009-08-05 13:44:25) (reply to #6) Zypper should make a summary: 1. new rpmnew,rmpold files 2. How many of rpmnew,rpmold files were sitting around before action + #8: Michal Hrusecky (-miska-) (2009-08-05 16:05:07) (reply to #7) + As users should be notfied about other things as well after update, + notifications shouldn't be handled by zypper (we've got Yast too) but + we will need some general mechanism to notify user. And probably rpm + should generate message about new configurations file conflict. But + this message should be one of many possible messages (sometimes some + other important user action is needed after update). I think users + notifications are already discussed in feature#301175 (301175) . + I also created wiki (http://en.opensuse.org/Configuration_Merge) page + for this feature some time ago. -- openSUSE Feature: https://features.opensuse.org/306411

1 0

[openFATE 305553] zypper: dist upgrade could error out if more than one repository with a base product exists
by fate_noreply＠suse.de 05 Aug '09

05 Aug '09

Feature changed by: Ján Kupec (jkupec) Feature #305553, revision 26 Title: zypper: dist upgrade could error out if more than one repository with a base product exists openSUSE-11.2: Candidate Priority Requester: Important Projectmanager: Important Requested by: Dirk Mueller (dirkmueller) Description: I've just learned over lunch that calling "zypper dup" is wrong if you have both buildservice repositories and a distribution repository enabled. apparently one has to call it with -r name, where name points to the distribution one wants to upgrade to, and the other repositories (e.g. buildservice addons) must not be dup'ed, but only updated via update -t package. I've verified that this indeed fixes the "reinstalling/downgrading package" issues everyone seems to be complaining about. It would be nice if zypp/zypper could detect this situation and advise the user, or alternatively do the right thing automatically. I'm not sure if channels of distributions (e.g. the factory channel, or a future openSUSE 11.0 channel) can be detected in some way.. if it does, then it could automatically add the -r argument if there is only one distribution channel enabled, and altneratively error out if more than one distribution channel is in the sources list and no -r argument was given. Relations: - make zypper dup error out if more than one repository exists (novell/bugzilla/id: 385972) https://bugzilla.novell.com/show_bug.cgi?id=385972 Discussion: #1: Stephan Kulow (coolo) (2008-05-11 02:20:39) * ** Bug 388956 has been marked as a duplicate of this bug. *** #2: Duncan Mac-Vicar (dmacvicar) (2008-12-10 15:31:24) Hm. If that is so, this feature is really important :O) Just a side question: how does installation handle this (if at all)? Currently they can't, we need to add means of such identification (as well as identification of update repos). yup, sounds good #3: Lukas Ocilka (locilka) (2008-05-12 06:17:43) Installation/Upgrade has the installation repository registered as the fist one, then Add-Ons or other repositories can be added or enabled. Upgrade doesn't handle how the packages are selected to be upgraded, it just calls solver. OK, some packages are dropped by installation by default :) See bug #300540. #4: Stephan Kulow (coolo) (2008-05-12 06:25:06) the main difference: it's pretty unusual to have 13 repos during distribution update with very comparable versions. While it's not to for zypper dup. BTW: another difference: installations sets YAST_IS_RUNNING=instsys, which some packages cause not to produce errors on updates. This might be good for dup, but bad for update #5: Duncan Mac-Vicar (dmacvicar) (2008-12-10 16:56:35) Note, I moved the bugzilla entry to fate, but mls claims the bug is invalid, as it is a perfect use case to do dist upgrade with various repositories. So this feature has to be evaluated with care and gathering opinions from various sources. It may be invalid. #7: Jiri Srain (jsrain) (2008-12-11 07:58:04) (reply to #5) I don't think it is invalid; I happened to downgrade several packages from OSS repo via zypper dup :-( #8: Duncan Mac-Vicar (dmacvicar) (2008-12-11 10:10:32) (reply to #7) The solution of stop-with-error if there is more than one repository is invalid because prevent the valid usecase of dist-upgrading with more than one repo enabled (as mls pointed out). What is valid about the feature, is that multiple repo upgrade can be dangerous, and we may warn the user if there are repos for different products there. #9: Jiri Srain (jsrain) (2008-12-11 10:53:42) (reply to #8) Sorry for not being precise in my comment: of course user must be able to override this error/warning/whatever. #6: Duncan Mac-Vicar (dmacvicar) (2008-12-10 18:34:19) Idea from mls: Use the CPE ids introduced in 11.1 to issue a warning if repositories are mixed. #10: Ján Kupec (jkupec) (2009-06-24 09:33:26) Michael, is this still relevant? Is this related to the planned --from option? #11: Michael Schröder (mlschroe) (2009-06-24 11:33:46) (reply to #10) This has nothing to do with --from, it's about doint 'zypper dup' to update the system to the next release while still having old repositories enabled. #12: Ján Kupec (jkupec) (2009-07-07 16:26:43) (reply to #11) So multiple repositories are not a problem in general, but multiple repos for different products are! OK, so now back to the solution: can you tell me or point me to some info abou these CPEs Duncan mentions in c#6? I guess they are part of the product solvable and are available as solv attribute? If so, all that's needed is to check whether there are multiple repos with a different product and write a warning if that's the case, right? #13: Michael Schröder (mlschroe) (2009-07-07 16:34:14) (reply to #12) ma, is there a libzypp interface? #14: Michael Andres (mlandres) (2009-07-13 14:16:11) (reply to #13) Yes. Since you can ask for a products CPEid, or for the CPEids related to a repository (supported or updated products). But I don't know if those CPEids are meanwhile included in the metadata (see bnc #459527). #15: Ján Kupec (jkupec) (2009-07-14 18:17:17) (reply to #14) OK, so this should not be too much work. So to sum it up: * zypper: show a warning in 'dup' if there are multiple base repos with different CPEids enabled. * metadata: check/include the CPEid in product metadata (who should do this?) #16: Ján Kupec (jkupec) (2009-07-27 17:30:09) (reply to #14) Rudi, please look at c#14 and 15 #17: Ján Kupec (jkupec) (2009-07-29 19:04:40) Current status: * TODO: put CPE IDs to content/prodcuts.xml metadata (still nobody assigned to do this!) * TODO: satsolver will need to parse the above (or is this ready already?) * PROBLEM: we need to figure out which repos don't go together for dup. I proposed to compare CPEs of 'base' or 'platform' repos, but we have no 'isBase' flag in product or repo metadata. Simply checking for different CPEs is not enough (think of one base product and one addon - two different CPEs, but 'dup' is OK with them). * PROBLEM: even if we'll have the 'isBase' flag, we'll be stuck in case of two different, but compatible bases, like e.g. SLES and SLED could be used standalone or with SLED as an add-on to SLES in the past. Do we still allow this? Any ideas? #18: Ruediger Oertel (oertel) (2009-07-30 17:20:05) adding more data (like the CPE-ids) is not a big issue. the problem for me is rather how to obtain a CPE-id #19: Marcus Meissner (msmeissn) (2009-08-04 17:55:08) CPE ids can be defined by the vendor as I udnerstand ;) I mailed Jan and Rudi. my suggestions would be: cpe:/o:opensuse:opensuse:11.1 cpe:/o:novell:suse_linux_enterprise:11:ga:server cpe:/o:novell: suse_linux_enterprise:10:sp2:desktop #20: Ralph Ulrich (ulenrich) (2009-08-05 13:25:05) (beginners question) Why products at all. Debian/Ubuntu do have so called meta-packages , which are normal package that pull in stuff: minimal, standard ...etc Without products you would loose an additional level of complication? + #21: Ján Kupec (jkupec) (2009-08-05 15:02:36) (reply to #20) + Using metapackages for puling stuff does not exlude using of CPE ID. + It's just means to uniquely identify a product and can be used by + Debian's metapackages as well. + Other than that, your question is not related to this FATE, and is more + appropriate for opensuse-softwaremgmt(a)opensuse.org mailing list. But + you might find the answer also here + http://en.opensuse.org/Product_Management -- openSUSE Feature: https://features.opensuse.org/305553

1 0

[openFATE 307185] XPLAT need to support DFS junctions
by fate_noreply＠suse.de 05 Aug '09

05 Aug '09

Feature added by: Sudhakar GNVS (ssudhakar) Feature #307185, revision 1 Title: XPLAT need to support DFS junctions Requested by: Sudhakar GNVS (ssudhakar) Description: Currently XPLAT APIs do not support DFS junctions. There is no way to detect and traverse a link and connect to a different server using XPLAT APIs. The xplat support for it is partially available in xtier and xplat need to make use of it. Resolving the followig bugs by making this FATE entry: 309793 309830 493023 -- openSUSE Feature: https://features.opensuse.org/307185

1 0

[openFATE 306411] Configuration files merge
by fate_noreply＠suse.de 05 Aug '09

05 Aug '09

Feature changed by: Ralph Ulrich (ulenrich) Feature #306411, revision 15 Title: Configuration files merge openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Michal Hrusecky (-miska-) Description: If we want to make our distribution friendly even to advanced users, I think that we shouldn't touch users configuration files. Luckily this isn't problem as in spec file Ican state that this file is configuration and I don't want to replace it if user did some manual changes. Or I can say that I want to replace it and keep backup of original one. But what I'm missing is some tool to easily merge these files. In Gentoo there is etc-update (http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=3&chap=4#doc_…) or dispatch-conf (http://en.gentoo-wiki.com/wiki/Dispatch-conf) . I'll describe more precisely what feature I'm missing and why I think it's needed. Let's say that I've got some package and there was quite big change in package default configuration file which will affect most of the users. On the other hand users can have pretty complicated constructions in their configuration files and if they did something like that, it's quite possible that they don't need to update their configuration file. So it is needed to tell users that if they are experiencing problems it is most likely because they touched default configuration. I can take care of it manually, mention it in various README and such, but more easier way would be following. User installs some packages. At the end of zypper or yast installation there will be warning "You've got 42 configuration files to merge, please run etc-update/dispatch-conf/whatever". Then user will run some easy interactive tool which will state which configuration files can use some manual merging, it will allow user to see difference between them and let him choose which one he wants or let him merge them manually somehow. Same warning about unmerged configuration files should appear each time user installs something, no matter if this installation didn't add any conflict, until all conflicts are fixed. User will be warned about possible problems, hacker can play with it and keep his changes against distribution defaults and ordinary user will just click on "use distribution default for all" if he ever encounter such a problem (shouldn't happen as ordinary user wouldn't touch configuration files). I explained basic expected work flow, so now what I think should be supported: * detect configuration files, their conflicts and allow their merge - this shouldn't be a big problem as rpm already stores conflicting files as .rpmnew/.rpmold * we probably want to keep even old versions to support three way merge to achieve even better results * if we are already storing these configuration files, maybe we should let users to backup their own changes as well, add support for versioning these configuration files * warn user that he has conflicts in configuration files - will require a little bit yast/zypper integration * merging tool should support both console and graphical interface (maybe use yast as possible frontend) * support for various formats (expandable by plugins) - ordinary diff may not be the best tool for merging XML files or ini files * ordinary user who don't change anything shouldn't need to know about this tool Relations: - Debian-like dist-upgrade live system full version upgrade (feature/id: 305634) Discussion: #1: Michal Hrusecky (-miska-) (2009-06-02 09:49:38) I was thinking about this a little bit more and if we want to support some kind of versioning and we want to use plugins for getting differences, it may be a good idea to request that plugins will be capable not only of producing nice output of difference between configuration files, but it probably should be able to apply it (behave not only as a 'diff', but also as a 'patch'). And we can build some simple version control system on top of it. Advantages: * can handle non-plain text files better (via plugins) * we can implement feature to discard or merge several commits into one to save space/make commit log more readable * can handle nicelly even insane configuration files like sqlite database or compressed directory with configuration files or any other binary format Disadvantages: * probably worse handling of text files * another thing to maintain/possible source of bugs #2: Stephan Kulow (coolo) (2009-06-09 11:51:14) this sounds like a lot of work to do right and with little gain. We lived quite well for years without it and whatever tool you come up will create new problems, there won't be a perfect tool. Applications with very bizzare config format usually come with their own configuration update tool that can be called from %post So I would put very low imporance on this. #3: Andreas Jaeger (a_jaeger) (2009-06-09 14:20:14) (reply to #2) The question is what is really needed to do here. If we could take some scripts from Gentoo and those would work without changes - cool. If we would need to change each and every config file for this, I'm also for rejecting. So, for me it's not clear what the cost is. #4: Michal Hrusecky (-miska-) (2009-06-12 16:12:55) (reply to #3) Well, merging utility can be probably ported from Gentoo with few minor tweaks (although it would be console only utility) or it could be written from scratch (with possible features in mind). This shouldn't be a big problem (it will just take some time). In feature #305634 comment #19 there is even an example how to write such a simple utility. With current rpm workflow, I think there is no need for packages changes. Only thing that would need some adjustements for this feature to be fully functional is integration with yast/zypper so thay will print warning about possible conflicts. I wouldn't suggest to force people to solve, just printing that there are some and that they should solve them using this utility should be enough. So it will need just some hack/new feature in installation procedure - run a program and allow it to create some notification for user. This is probably related to feature #301175 (301175) #5: Michael Andres (mlandres) (2009-06-15 12:02:05) (reply to #3) Libzypp checks for changed configfiles, and if they differ the 'diff' output is written to /var/log/YaST2/ (I don't know if YaST still mails this to root). Notification is also /var/log/zypp/history, and AFAIK zypper displays some info as well. But it's not a big deal to have a more flexible consumer for this information. The easiest would be to check for the presence of a certain script (or a directory containing scripts), and if it exists invoke it with package names and configfiles as argument. Then you can install any handler you like. #6: Elmar Stellnberger ATK (estellnb) (2009-08-04 11:48:04) At Bug 506815, Comment #2 we have a more simple proposial simply notifying the user about changes in configuration files and selecting an appropriate .rpmnew/.rpmold strategy. This should be the first thing to be implemented in this regard before we can move on to fancier things like an interactive auto-diff&merge (https://bugzilla.novell.com/show_bug.cgi?id=506815#c2). I personally would not regard the gain as little since forgetting to re- create config files can be very tedious especially if you forget about it and especially if there are regular upgrades as for the buildservice repos. + #7: Ralph Ulrich (ulenrich) (2009-08-05 13:44:25) (reply to #6) + Zypper should make a summary: + 1. new rpmnew,rmpold files + 2. How many of rpmnew,rpmold files were sitting around before action + -- openSUSE Feature: https://features.opensuse.org/306411

1 0

[openFATE 305553] zypper: dist upgrade could error out if more than one repository with a base product exists
by fate_noreply＠suse.de 05 Aug '09

05 Aug '09

Feature changed by: Ralph Ulrich (ulenrich) Feature #305553, revision 25 Title: zypper: dist upgrade could error out if more than one repository with a base product exists openSUSE-11.2: Candidate Priority Requester: Important Projectmanager: Important Requested by: Dirk Mueller (dirkmueller) Description: I've just learned over lunch that calling "zypper dup" is wrong if you have both buildservice repositories and a distribution repository enabled. apparently one has to call it with -r name, where name points to the distribution one wants to upgrade to, and the other repositories (e.g. buildservice addons) must not be dup'ed, but only updated via update -t package. I've verified that this indeed fixes the "reinstalling/downgrading package" issues everyone seems to be complaining about. It would be nice if zypp/zypper could detect this situation and advise the user, or alternatively do the right thing automatically. I'm not sure if channels of distributions (e.g. the factory channel, or a future openSUSE 11.0 channel) can be detected in some way.. if it does, then it could automatically add the -r argument if there is only one distribution channel enabled, and altneratively error out if more than one distribution channel is in the sources list and no -r argument was given. Relations: - make zypper dup error out if more than one repository exists (novell/bugzilla/id: 385972) https://bugzilla.novell.com/show_bug.cgi?id=385972 Discussion: #1: Stephan Kulow (coolo) (2008-05-11 02:20:39) * ** Bug 388956 has been marked as a duplicate of this bug. *** #2: Duncan Mac-Vicar (dmacvicar) (2008-12-10 15:31:24) Hm. If that is so, this feature is really important :O) Just a side question: how does installation handle this (if at all)? Currently they can't, we need to add means of such identification (as well as identification of update repos). yup, sounds good #3: Lukas Ocilka (locilka) (2008-05-12 06:17:43) Installation/Upgrade has the installation repository registered as the fist one, then Add-Ons or other repositories can be added or enabled. Upgrade doesn't handle how the packages are selected to be upgraded, it just calls solver. OK, some packages are dropped by installation by default :) See bug #300540. #4: Stephan Kulow (coolo) (2008-05-12 06:25:06) the main difference: it's pretty unusual to have 13 repos during distribution update with very comparable versions. While it's not to for zypper dup. BTW: another difference: installations sets YAST_IS_RUNNING=instsys, which some packages cause not to produce errors on updates. This might be good for dup, but bad for update #5: Duncan Mac-Vicar (dmacvicar) (2008-12-10 16:56:35) Note, I moved the bugzilla entry to fate, but mls claims the bug is invalid, as it is a perfect use case to do dist upgrade with various repositories. So this feature has to be evaluated with care and gathering opinions from various sources. It may be invalid. #7: Jiri Srain (jsrain) (2008-12-11 07:58:04) (reply to #5) I don't think it is invalid; I happened to downgrade several packages from OSS repo via zypper dup :-( #8: Duncan Mac-Vicar (dmacvicar) (2008-12-11 10:10:32) (reply to #7) The solution of stop-with-error if there is more than one repository is invalid because prevent the valid usecase of dist-upgrading with more than one repo enabled (as mls pointed out). What is valid about the feature, is that multiple repo upgrade can be dangerous, and we may warn the user if there are repos for different products there. #9: Jiri Srain (jsrain) (2008-12-11 10:53:42) (reply to #8) Sorry for not being precise in my comment: of course user must be able to override this error/warning/whatever. #6: Duncan Mac-Vicar (dmacvicar) (2008-12-10 18:34:19) Idea from mls: Use the CPE ids introduced in 11.1 to issue a warning if repositories are mixed. #10: Ján Kupec (jkupec) (2009-06-24 09:33:26) Michael, is this still relevant? Is this related to the planned --from option? #11: Michael Schröder (mlschroe) (2009-06-24 11:33:46) (reply to #10) This has nothing to do with --from, it's about doint 'zypper dup' to update the system to the next release while still having old repositories enabled. #12: Ján Kupec (jkupec) (2009-07-07 16:26:43) (reply to #11) So multiple repositories are not a problem in general, but multiple repos for different products are! OK, so now back to the solution: can you tell me or point me to some info abou these CPEs Duncan mentions in c#6? I guess they are part of the product solvable and are available as solv attribute? If so, all that's needed is to check whether there are multiple repos with a different product and write a warning if that's the case, right? #13: Michael Schröder (mlschroe) (2009-07-07 16:34:14) (reply to #12) ma, is there a libzypp interface? #14: Michael Andres (mlandres) (2009-07-13 14:16:11) (reply to #13) Yes. Since you can ask for a products CPEid, or for the CPEids related to a repository (supported or updated products). But I don't know if those CPEids are meanwhile included in the metadata (see bnc #459527). #15: Ján Kupec (jkupec) (2009-07-14 18:17:17) (reply to #14) OK, so this should not be too much work. So to sum it up: * zypper: show a warning in 'dup' if there are multiple base repos with different CPEids enabled. * metadata: check/include the CPEid in product metadata (who should do this?) #16: Ján Kupec (jkupec) (2009-07-27 17:30:09) (reply to #14) Rudi, please look at c#14 and 15 #17: Ján Kupec (jkupec) (2009-07-29 19:04:40) Current status: * TODO: put CPE IDs to content/prodcuts.xml metadata (still nobody assigned to do this!) * TODO: satsolver will need to parse the above (or is this ready already?) * PROBLEM: we need to figure out which repos don't go together for dup. I proposed to compare CPEs of 'base' or 'platform' repos, but we have no 'isBase' flag in product or repo metadata. Simply checking for different CPEs is not enough (think of one base product and one addon - two different CPEs, but 'dup' is OK with them). * PROBLEM: even if we'll have the 'isBase' flag, we'll be stuck in case of two different, but compatible bases, like e.g. SLES and SLED could be used standalone or with SLED as an add-on to SLES in the past. Do we still allow this? Any ideas? #18: Ruediger Oertel (oertel) (2009-07-30 17:20:05) adding more data (like the CPE-ids) is not a big issue. the problem for me is rather how to obtain a CPE-id #19: Marcus Meissner (msmeissn) (2009-08-04 17:55:08) CPE ids can be defined by the vendor as I udnerstand ;) I mailed Jan and Rudi. my suggestions would be: cpe:/o:opensuse:opensuse:11.1 cpe:/o:novell:suse_linux_enterprise:11:ga:server cpe:/o:novell: suse_linux_enterprise:10:sp2:desktop + #20: Ralph Ulrich (ulenrich) (2009-08-05 13:25:05) + (beginners question) Why products at all. Debian/Ubuntu do have so + called meta-packages , which are normal package that pull in stuff: + minimal, standard ...etc + Without products you would loose an additional level of complication? -- openSUSE Feature: https://features.opensuse.org/305553

1 0

[openFATE 307177] HP-ISS: Patch to the openIPMI
by fate_noreply＠suse.de 05 Aug '09

05 Aug '09

Feature added by: Ahmad Sadeghpour (sahmad) Feature #307177, revision 1 Title: HP-ISS: Patch to the openIPMI Requested by: Ahmad Sadeghpour (sahmad) Description: the existing openIPMI needs a patch - already upstream- hp-OpenIPMI is a fork of the distro IPMI plus some userspace tools. We don't want SLES to ship any version of hp-OpenIPMI, we just want Novell to backport "commit 4dec302", an upstream change to make the in-distro IPMI drivers feature-equivalent to the drivers provided by hp-OpenIPMI. http://git.kernel.org/linus/4dec302 -- openSUSE Feature: https://features.opensuse.org/307177

1 0

[openFATE 120340] Run download and install in parallel
by fate_noreply＠suse.de 05 Aug '09

05 Aug '09

Feature changed by: Ralph Ulrich (ulenrich) Feature #120340, revision 98 Title: Run download and install in parallel openSUSE-10.2: Rejected by Klaus Kämpf (kwk) reject date: 2006-08-09 11:36:10 reject reason: Not possible in 10.2 timeframe Priority Requester: Important openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-08-01 10:25:01 reject reason: Out of time. Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Jiri Srain (jsrain) reject date: 2008-03-28 13:56:11 reject reason: Out of resources for 11.0. Priority Requester: Important Projectmanager: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-11 12:06:35 reject reason: This needs to wait. Postponing. Priority Requester: Important Projectmanager: Important openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-06-03 08:43:03 reject reason: No resources for 11.2. Priority Requester: Important Projectmanager: Important openSUSE-11.3: Evaluation Priority Requester: Important Projectmanager: Important Requested by: Klaus Kämpf (kwk) Requested by: Peter Poeml (poeml) Requested by: Reinhard Max (rmax) Description: Network installation could be improved by running package download and package installation in parallel. References: https://bugzilla.novell.com/show_bug.cgi?id=60844 https://bugzilla.novell.com/show_bug.cgi?id=209799 https://bugzilla.novell.com/show_bug.cgi?id=128050 https://bugzilla.novell.com/show_bug.cgi?id=370457 https://bugzilla.novell.com/show_bug.cgi?id=370054 https://bugzilla.novell.com/show_bug.cgi?id=385711 http://en.opensuse.org/Libzypp/Failover http://metalinker.org/ Fate #300660: Download package groups before install Discussion: #2: Klaus Kämpf (kwk) (2006-08-09 11:36:42) Michael already looked at this. Should be further evaluated for 10.3 #3: Edith Parzefall (emapedl) (2007-07-31 16:56:12) Problem is: what do we do if we lost the network connection when only half the packages are installed? #7: Reinhard Max (rmax) (2008-04-10 11:42:43) (reply to #3) I think this is a general problem for network based installations. Can you elaborate if/why you see this as a special problem when download and installation are running in parallel? #8: Peter Poeml (poeml) (2008-05-19 14:49:53) (reply to #7) For reliable operation of a business critical server, it is a must that packages are downloaded first, before the installation/update is started. Otherwise a network outage can lead to a broken system which is half updated. So if parallel download/install is implemented (for desktop users, maybe...) then please make sure that it is possible to disable it. #9: Reinhard Max (rmax) (2008-05-19 16:01:15) (reply to #8) As we just sorted out on IRC, the current implementation also doesn't allow to complete download before starting installation and the feature proposed here wouldn't make this worse. But as the wish of server admins to have all packages downloaded before starting to install them is very valid, I think we should extend this feature request to contain that requirement as well, and probably rename it to "decouple download and installation". If download and installation are properly decoupled, it should just be a matter of the parameters the algorithm is called with to get one of the following behaviours: * Download and install packages one by one (as it is now) * Keep downloading subsequent packages while installing (as originally proposed here) * Use a fixed-size download cache for flow control between download an installations (in situations where download is faster than installation and disk space is limited) * Download all packages of an update or installation and install them afterwards (as requested by Peter for server admins) #10: Jiri Srain (jsrain) (2008-05-20 10:22:10) (reply to #9) We already do have similar feature: #300660: Download package groups before install #4: Edith Parzefall (emapedl) (2007-07-31 16:57:22) Please reject for 10.3. #5: Duncan Mac-Vicar (dmacvicar) (2008-01-10 16:23:46) This is included in the ZYpp plan for 11.0, however implementation will start after beta. Will keep in evaluation, it depends on other milestones for beta1 #14: Chris Hills (chaz6) (2009-02-16 16:42:06) Is there a feature request to install using both the base and updates repo so that the latest packages available at install-time are used, thus saving bandwidth? #15: Jiri Srain (jsrain) (2009-02-17 08:45:38) (reply to #14) This is how it works for quite some time. Repositories providing patches also provide the packages so that they can be installed directly from the update repositories (provided they contain newer version). #16: Duncan Mac-Vicar (dmacvicar) (2009-06-02 15:18:00) For 11.2 we will focus on flexibility of the download and install order (like installing after everything is downloaded), however parallel stuff should be done after we have this in place. Please reject. #20: Jörn Knie-von Allmen (phisiker) (2009-08-05 12:12:29) (reply to #16) Please do not reject. With a downloadprotocol this should be solvable. The Installtask can poll an that protocol (or be informed by a Signal when a download has ended. This is better then polling. Or if prefering an IPC-Framework: D-BUS. Never mind!). Such problems I had some times often to solve (but in Java) and generally, it isn't so dificult. + #21: Ralph Ulrich (ulenrich) (2009-08-05 13:03:25) (reply to #20) + Please reject forever: As operating system are sort of highly + integrated databases there should be a commit like funcutionality: + First download then install (like debian). Otherwise repositories + representing a rolling release (factory) will potentially break an + updating system. #17: Michal Papis (mpapis) (2009-07-04 20:58:23) I think great example here may be Gentoo, there You can chose the way of getting packages, by default download and installation go in paraler, but it is possible to get first sources and then run build/installation. If you are on the default and something breaks, ex. network, Yuo can always resume the last download&installation task. #18: Giuseppe Salinaro (superpeppo89) (2009-07-16 19:37:27) (reply to #17) This idea of gentoo is good... #19: Ján Kupec (jkupec) (2009-07-20 10:59:31) (reply to #18) Guys, as Duncan wrote in c#16, we are already developing the "download all, install all" mode (currently we only have "download one, install one, ..."), and yes, users will be able to choose one of these. This particular feature would be an improvement of the current mode: "download one, install one while downloading others, ...". I hope this clarifies the current status a bit. -- openSUSE Feature: https://features.opensuse.org/120340

1 0

[openFATE 305317] Default to hidden bootloader menu
by fate_noreply＠suse.de 05 Aug '09

05 Aug '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305317, revision 20 Title: Default to hidden bootloader menu - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) + reject date: 2009-08-05 12:17:52 + reject reason: out of resources for 11.2. Priority Requester: Desirable Projectmanager: Desirable + openSUSE-11.3: New + Priority + Requester: Desirable Info Provider: Jan Engelhardt (jengelh) Requested by: Jiri Srain (jsrain) Description: As long as there is no other operating system present (SUSE is the only system), it makes sense to default to hidden bootloader menu (and booting directly). References: http://www.gnu.org/software/grub/manual/grub.html#Hidden-menu-interface https://bugzilla.novell.com/show_bug.cgi?id=425717 Discussion: #1: Stephan Kulow (coolo) (2009-04-16 10:34:48) I like that idea. I guess it's a tiny change for bootloader, but has possibly some docu impact. #2: Stanislav Visnovsky (visnov) (2009-05-28 16:45:13) How should it behave with option to keep kernels from updates (libzypp option)? What about failsafe? #3: Jiri Srain (jsrain) (2009-06-01 11:21:11) From the GRUB documentation: When your terminal is dumb or you request GRUB to hide the menu interface explicitly with the command `hiddenmenu' (*note hiddenmenu::), GRUB doesn't show the menu interface (*note Menu interface::) and automatically boots the default entry, unless interrupted by pressing ESC. When you interrupt the timeout and your terminal is dumb, GRUB falls back to the command-line interface (*note Command-line interface::). This sounds to me like this GRUB feature is intended for different purpose, and the use case described here does not make much sense (unlike lowering the time-out to e.g. 1 second). Torsten, what is your view? According to the documentation, GRUB allows to display the boot menu via pushing the Escape button. #7: Christoph Thiel (cthiel1) (2009-07-16 11:27:26) (reply to #3) Torsten, could you please provide your view on this? Fedora and others seem to be doing this for years. #4: T. J. Brumfield (enderandrew) (2009-06-13 03:31:06) This option would only be utilized when no other OS is present, and you can still get back to the menu with Esc. This isn't that much different than needing F8 for the boot menu for Windows. It would speed up boot times. How is that a bad thing? #5: Jan Engelhardt (jengelh) (2009-06-18 23:53:45) Does not Fedora do something similar? #6: Christoph Thiel (cthiel1) (2009-06-28 10:00:44) (reply to #5) I haven't looked at how Fedora handles this. Jan, would you be able to dig into what Fedora does technically? This would be very much appreciated! #8: Stefan Kunze (kunzes) (2009-07-28 16:03:50) The only problem I see with this is when the installer does not pick up another installed OS (happens to Windows once in a while) and defaults to a hidden Bootloader? -- openSUSE Feature: https://features.opensuse.org/305317

1 0