August 2009 - openSUSE Features - openSUSE Mailing Lists

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

11 Aug '09

Feature changed by: Michael Löffler (michl19) Feature #306411, revision 18 Title: Configuration files merge - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Michael Löffler (michl19) + reject date: 2009-08-11 15:58:40 + reject reason: too late for 11.2 Priority Requester: Desirable + openSUSE-11.3: 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. #9: Stanislav Brabec (sbrabec) (2009-08-06 12:43:40) (reply to #8) User notification were also topic of: http://lists.opensuse.org/zypp-devel/2009-05/msg00001.html https://features.opensuse.org/305307 may be interesting way to inform as well (especially for auto updates) -- openSUSE Feature: https://features.opensuse.org/306411

1 0

[openFATE 307258] Default kdesu to use sudo and not su
by fate_noreply＠suse.de 11 Aug '09

11 Aug '09

Feature added by: Bill P (google01103) Feature #307258, revision 1 Title: Default kdesu to use sudo and not su openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Bill P (google01103) Description: as described in the article http://www.benkevan.com/blog/default-kdesu-to-use-sudo-and-not-su/ -- openSUSE Feature: https://features.opensuse.org/307258

1 2

[openFATE 307195] Making Gnome Power Manager more customisable
by fate_noreply＠suse.de 11 Aug '09

11 Aug '09

Feature added by: Marcel Müller (open_assistant) Feature #307195, revision 1 Title: Making Gnome Power Manager more customisable openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: Marcel Müller (open_assistant) Description: In the Gnome power manager the lowest time to turn the desktop automatically off is 11 minutes, I think it should be able to choose a lower time. -- openSUSE Feature: https://features.opensuse.org/307195

1 2

[openFATE 307198] Integrate YaST2 modules into SystemSettings and eliminate Yast2's duplicated
by fate_noreply＠suse.de 11 Aug '09

11 Aug '09

Feature added by: usr oss (usross) Feature #307198, revision 1 Title: Integrate YaST2 modules into SystemSettings and eliminate Yast2's duplicated openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: usr oss (usross) Description: I know http://svn.opensuse.org/svn/yast/branches/tmp/tgoettlicher/yast2cc_rewrite/ (http://svn.opensuse.org/svn/yast/branches/tmp/tgoettlicher/yast2cc_rewrite/) but... openSUSE's graphic tools (Yast2 modules) must be into KDE SystemSettings (as is already doing a known distro) because the things must be most standard as possible (as now with the packagekit project for install software) at the GNU/Linux world (where there are already many differences). If each distro develops its own Control Center, is a chaos; like install software was before packagekit. -- openSUSE Feature: https://features.opensuse.org/307198

1 5

[openFATE 305591] Define Purpose for each openSUSE Build Service Project
by fate_noreply＠suse.de 11 Aug '09

11 Aug '09

Feature changed by: Andreas Jaeger (a_jaeger) Feature #305591, revision 7 - Title: Define purpose for each project + Title: Define Purpose for each openSUSE Build Service Project Buildservice: Evaluation Priority Requester: Important Requested by: Pavol Rusnak (prusnak) Description: define purpose for each project, like: * add-on package * fresh packages + libraries (eg. games) * bleeding edge packages (eg. zypp:svn) * backports for older distributions (eg. zypp:Backport) * playground (eg. all home projects) So, * this sets users expectations * purpose could be indicated by naming conventions, or even better by project flags * purpose must be shown in the search result for this method to work References: http://lists.opensuse.org/opensuse-buildservice/2008-12/msg00056.html + Discussion: + #1: Andreas Jaeger (a_jaeger) (2009-08-11 15:51:09) + This sounds like a good idea. What needs to be done to make this + happen? -- openSUSE Feature: https://features.opensuse.org/305591

1 0

[openFATE 307184] fix bluetooth
by fate_noreply＠suse.de 11 Aug '09

11 Aug '09

Feature added by: Bruce Ferrell (rbf072858) Feature #307184, revision 1 Title: fix bluetooth openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Bruce Ferrell (rbf072858) Description: pairing to bluetooth devices is broken. using gnome utilities to do it is unacceptable -- openSUSE Feature: https://features.opensuse.org/307184

1 2

[openFATE 305473] virt-manager: add option to set the keymap via UI for every VM
by fate_noreply＠suse.de 11 Aug '09

11 Aug '09

Feature changed by: Andreas Jaeger (a_jaeger) Feature #305473, revision 10 Title: virt-manager: add option to set the keymap via UI for every VM - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Andreas Jaeger (a_jaeger) + reject date: 2009-08-11 15:49:01 + reject reason: too late for 11.2 Priority Requester: Important Projectmanager: Desirable Requested by: Michael Calmer (mcalmer) Description: If the default keyboard mapping does not work, it is difficult to set the keymap manual. A option in virt-manager to change the keymap setting via the UI for a single VM would be good to have. See also Bug #444632 Relations: - Wrong default keymap configured. Cannot enter important chars with vncviewer (novell/bugzilla/id: 444632) https://bugzilla.novell.com/show_bug.cgi?id=444632 -- openSUSE Feature: https://features.opensuse.org/305473

1 0

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

11 Aug '09

Feature changed by: Andreas Jaeger (a_jaeger) Feature #305336, revision 31 Title: Ship man page for every executable - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Andreas Jaeger (a_jaeger) + reject date: 2009-08-11 15:41:47 + reject reason: This is a task that should be done in cooperation with + the upstream projects. Priority Requester: Mandatory Requested by: Matthias Eckermann (mge1512) Description: 1. Even graphical applications need docs outside the application itself. The need to run the application, to know what does it does, is not good. 2. You need a standard documentation format; where standard = expected for people needing that documentation. Who are, often, not knowing the distro well (so the format can't be distro-specific). And the format must be the same for all binaries/packages. One can't rely on the fact it will always be easy and intuitive to find that some application is part KDE (for example) and one can get the documentation in konqueror when typing 'help:/application'. 3. To view the documentation must be as easy as possible and with as minimal resources as possible. This is why online documentation is not so good (you need a running Internet net connection), documentation in a web browser as well (you need X and graphical desktop). HTML is questionable as it (as a format) allows so many extensions that it is needed to expect that such documentation will not be readable in text browsers after some time. 4. Many parts are shared between openSUSE and the enterprise products. And, in the enterprise world, we need to be much more standard conforming. Including the documentation. A UNIX admin will use the 'man' command for getting info about the binary. 'info' system is here as well, for many years. But 'man' is still more usual. Imagine a server room with hundreds/thousands of servers of several UN*X clones - 'man' works everywhere, and Linux is expected to be "on par" also with respect to those capabilities. These four points stay behind the idea of man pages needed and provided for everything. Relations: - How to Create Manpages with DocBook (url: http://en.opensuse.org/Manual_Pages/How_to_Create_Manpages_with_DocBook) - At http://en.opensuse.org/Manual_Pages/Missing a list of all packages with missing man pages can be found (url: http://en.opensuse.org/Manual_Pages/Missing) Use Case: User / Administrator should find a dedicated man page for every executable in openSUSE and SUSE Linux Enterprise systems. Discussion: #2: Stefan Behlert (sbehlert) (2008-10-22 15:00:11) I agree with the intention, but shouldn't it be rather 'documentation for each executable'? Newer stuff uses mostly info-pages, afaiks #3: Matthias Eckermann (mge1512) (2008-11-10 14:31:15) (reply to #2) It is valid to have a pointer to the info pages in the man-pages, sure. But man-pages are the UNIX proposed way of doing documentation. #9: Thomas Schraitle (thomas-schraitle) (2009-02-20 09:54:09) IMHO DocBook would be very suitable for this task as nobody has to learn the awkward syntax of groff/troff/... For example, I've submitted a DocBook file to the scout author and he generates the manpage with the DocBook stylesheets automatically. If you think, a manpage is not enough, each DocBook file can be easily transformed into (X)HTML, PDF, or almost any other output formats. IHMO it saves time if you want to support more formats than just manpage. The whole process is documented here: http://en.opensuse.org/Manual_Pages/How_to_Create_Manpages_with_DocBook #10: Jan Engelhardt (jengelh) (2009-02-21 20:31:14) (reply to #9) Manpages are very suitable for this task as nobody has to learn the awkward DocBook syntax. If done right, manpages are just another markup language and there are just a few elements one needs to know. (You can even count them in your hands: .TH, .SH, .SS, .PP, .TP, .nf/.fi, \fB, \fI, \fP, and sometimes . IP. They almost map to HTML's title, h1, h2, p, (no direct eqv), pre, b, i, /b|/i, and ol|ul, respectively.) #11: Praveen Kunjapur (stilo_vingyou) (2009-04-09 21:38:39) Knowledge is power. -- openSUSE Feature: https://features.opensuse.org/305336

1 0

[openFATE 306503] LiveCD: Save installer settings in case of abort and rerun
by fate_noreply＠suse.de 11 Aug '09

11 Aug '09

Feature added by: Jakub Rusinek (liviopl) Feature #306503, revision 1 Title: LiveCD: Save installer settings in case of abort and rerun openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Jakub Rusinek (liviopl) Description: Some people may encounter problems using installer and abort installation and rerun it later. Installer should remember settings to make their lives easier. -- openSUSE Feature: https://features.opensuse.org/306503

1 2

[openFATE 305147] Wizard mode for Network Card configuration (in YaST)
by fate_noreply＠suse.de 11 Aug '09

11 Aug '09

Feature changed by: Andreas Jaeger (a_jaeger) Feature #305147, revision 13 Title: Wizard mode for Network Card configuration (in YaST) - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Andreas Jaeger (a_jaeger) + reject date: 2009-08-11 15:36:00 + reject reason: A desktop applet is the better solution, see Ludwig's + proposal. Priority Requester: Neutral Requested by: Michal Zugec (mzugec) Description: (based on "Internet/Intranet with external Router" in suse-beta-e) It seems some users don't know how to setup the SuSEfirewall correctly. Especially, they don't know if they should setup a network card as internal or external device. If a network card is found, YaST should ask for its usage (local network or directly connected to the internet?) - every user should know. With this information the firewall setup can be done in a useful way. See bugzilla https://bugzilla.novell.com/show_bug.cgi?id=67415 Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:34:01) sounds reasonable. But how many multihomed systems do we find where the user "does not know" ? Besides, the security team's policy seems to be "lock everything, ask questions later", so I am not sure they are willing to mollify the firewall rules (for instance, open up Avahi by default, or other default daemons) on a "local" interface. Asking Marcus for insight. I am not sure on this one. #2: T. J. Brumfield (enderandrew) (2009-06-13 02:33:51) I'd contend that openSUSE and SLES/SLED should be treated differently here. With SLES/SLED, I'd err more on the side of caution and security, where as with openSUSE, I'd err more on the side of making the system user friendly. #3: Marcus Meissner (msmeissn) (2009-07-16 14:35:43) What we have investigated, or better Ludwig has investigated, is a Desktop Applet that can switch Firewall zones. See http://lizards.opensuse.org/2009/07/10/1453/ (Since most user machines these days are laptops, who vary between zones.) Perhaps this is more what is wanted? + #4: Andreas Jaeger (a_jaeger) (2009-08-11 15:35:28) (reply to #3) + I agree, let's push the applet instead. -- openSUSE Feature: https://features.opensuse.org/305147

1 0