June 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 305682] Implement the possibility to allow Add-on source from remote "Plain RPM directory"
by fate_noreply＠suse.de 02 Jun '09

02 Jun '09

Feature changed by: Jiri Srain (jsrain) Feature #305682, revision 6 Title: Implement the possibility to allow Add-on source from remote "Plain RPM directory" openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Stefan Assmann (assmannst) Partner organization: openSUSE.org Description: During installation when configuring an add-on product there is an option called "Local Directory". If you choose that the next window will have a checkbox "Plain RPM Directory" which allows to add a directory that only contains RPMs as an add-on source. Unfortunately this seems not to be available if you try to configure an add-on product that is not stored locally. Neither FTP, HTTP, SMB, NFS etc... have an option to add a "Plain RPM Directory". This is really useful for exchanging single or multiple RPMs during development without the need to wait for the next development snapshot to verify changes made to the RPMs install fine. Support for this should be implemented into autoyast as well. Gives the opportunity to automatically configure a plain rpm update add-on source for easy exchange of RPMs. Business case (Partner benefit): openSUSE.org: Improves development process because developers can test the influence of their changes to RPMs during installation without having to wait for the next development snapshot. Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 19:43:30) This is nice candy for developers. Good idea. #2: Christoph Thiel (cthiel1) (2009-05-28 14:30:47) (reply to #1) I'm unsure if remote plain rpm dirs make much sense. Directory listing + getting the metadata would be a pain. How about adding a hint on how to simply create a remote repo with just a few RPMs in there by running "createrepo" on that directory? + #3: Jiri Srain (jsrain) (2009-06-02 10:52:31) (reply to #2) + I agree with Christoph. Also remember that in general it is not + possible to list directories on remote sources (e.g. HTTP/HTTPS). + Add-on product consists of more than just the packages - it contains + some additional metadata with product description etc. Therefore one + needs to create some metadata anyway and plain directory cannot work as + an add-on product. -- openSUSE Feature: https://features.opensuse.org/305682

1 0

[openFATE 306411] Configuration files merge
by fate_noreply＠suse.de 02 Jun '09

02 Jun '09

Feature changed by: Michal Hrusecky (-miska-) Feature #306411, revision 5 Title: Configuration files merge openSUSE-11.2: New 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 -- openSUSE Feature: https://features.opensuse.org/306411

1 0

[openFATE 302311] Handle Bluetooth network in Networkmanager
by fate_noreply＠suse.de 02 Jun '09

02 Jun '09

Feature changed by: Luis Medinas (lmedinas) Feature #302311, revision 24 Title: Handle Bluetooth network in Networkmanager openSUSE-11.2: Evaluation Priority Requester: Important Projectmanager: Important Requested by: Stefan Behlert (sbehlert) Description: Networks created over Bluetooth should be handled in Networkmanager, too. This includes WiNet (UWB) References: http://bugzilla.gnome.org/show_bug.cgi?id=432774 Discussion: #1: JP Rosevear (jproseve) (2008-07-14 20:40:48) Bastien N. at RedHat has done some work here now after the somewhat failed initial upstream attempt. #2: JP Rosevear (jproseve) (2008-07-21 13:42:26) (reply to #1) Taking this only if upstream provides it. #3: JP Rosevear (jproseve) (2008-09-08 09:38:29) (reply to #2) Upstream has not provided it in time. + #4: Luis Medinas (lmedinas) (2009-06-02 05:38:42) + This feature has landed NetworkManager git. It should be available for + 0.7.2. -- openSUSE Feature: https://features.opensuse.org/302311

1 0

[openFATE 305403] Bootloader beep configuration
by fate_noreply＠suse.de 01 Jun '09

01 Jun '09

Feature changed by: Jiri Srain (jsrain) Feature #305403, revision 11 Title: Bootloader beep configuration - openSUSE-11.2: Evaluation + openSUSE-11.2: Candidate Priority Requester: Desirable Projectmanager: Desirable Requested by: Jiri Srain (jsrain) Description: Allow to configure whether the acoustic signal should be used for installed bootloader. Acoustic signal is valuable for visually impaired people, while it may be disturbing e.g. in libraries. Discussion: #1: Jiri Srain (jsrain) (2008-11-12 15:58:43) Default can be set depending on whether braille display was found or whether text-to-speech in isolinux was used. #2: Stefan Behlert (sbehlert) (2008-11-12 17:15:07) Is this feature meant as 'allow atuomatic setting of'? The beep is afaik already configurable to be 'off'. If not, this would be a bug. #3: Stefan Seyfried (seife) (2008-11-12 18:09:40) Please reject this feature. This is seriously overengineered. The beep now defaults to off int the installed system. If somebody wants to enable it, he can do so with gfxboot --change-config "boot::beep=1" Marco only needs to document that for his customers and everything is fine. Please, no YaST module for that. #4: Jiri Srain (jsrain) (2008-11-13 09:39:44) (reply to #3) It's not about a new module, just about a check box in the bootloader configuration. + #5: Jiri Srain (jsrain) (2009-06-01 11:38:11) (reply to #4) + Jozo, please, find a reasonable location for the check box. -- openSUSE Feature: https://features.opensuse.org/305403

1 0

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

01 Jun '09

Feature changed by: Jiri Srain (jsrain) Feature #305317, revision 9 Title: Default to hidden bootloader menu openSUSE-11.2: Evaluation Priority Requester: Desirable 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. -- openSUSE Feature: https://features.opensuse.org/305317

1 0

[openFATE 120115] Common Virtual File System Support
by fate_noreply＠suse.de 01 Jun '09

01 Jun '09

Feature changed by: Norbert Frese (nf2) Feature #120115, revision 31 Title: Common Virtual File System Support openSUSE-11.1: Rejected by JP Rosevear (jproseve) reject date: 2008-07-21 13:06:16 reject reason: Lack of time before feature freeze. Priority Requester: Important Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Joachim Werner (joachimwerner) Description: KDE and Gnome both use their own virtual file system layer to access protocols like SSH, WebDAV, FTP, or SMB (KIO slaves vs. gnome-vfs). This functionality should be available from all major desktop applications on both desktops. Different approaches could be taken: * Implement a lower-level VFS layer that can be used from all applications. This approach has obvious limits because all remote file systems would have to be "mounted" locally, which is not as flexible as accessing them via URLs. * Separate file loading and file storage from the application cores and use the desktop environments' native file dialogs. This approach has worked quite well for some applications (e.g. OpenOffice.org, Sodipodi), but may be a painsome process for others. * Use the useful parts from the non-KDE/non-Gnome applications and write new, native applications using those parts. This has been done with the Gecko rendering engine. Another example is gphoto2, which used to be a GTK application, but now is a library that is used in Gnome and KDE digital camera management frontends. How could we reach that goal? * KDE and Gnome developers at Novell should cooperate to develop a guideline for 3rd party developers. * Where possible, tools should be provided to help developers with using the native dialogs. Discussion: #1: Joachim Werner (joachimwerner) (2006-02-14 15:30:07) FUSE and user space filesystems like fusesmb or fuse_kio can deliver this. We need to put some effort into this post Code 10. #2: Stefan Behlert (sbehlert) (2008-05-21 21:15:25) Michael, you did some evaluation wrt. KDE/GNOME using common stuff. Anything helpful to add? #3: Gary Ekker (gekker) (2008-05-29 14:35:45) Given Novell and the communities recent investement in gvfs and the fact that KDE4 isn't using gvfs, I'm going to reject this one. #4: Michael Meeks (michael_meeks) (2008-06-03 11:14:21) Sure - this is a great direction to go in. Wrt. the different approaches - I want to use this as an opportunity to share code & reduce bug fixing / sustain costs: and of course to unify the ISV platform. I'm not that enthusiastic about FUSE from this angle: I would prefer a single implementation that can be compatibly wrapped by both existing KIO and GIO APIs. In addition, I believe we need to unify the wallet / keyring pieces since network IO slaves are fairly useless without that. #5: Joachim Werner (joachimwerner) (2008-06-06 11:37:22) I'm not quite sure I understand why this request is closed for 11. The problem persists, and AFAICS my initial description is still valid, regardless of the technology switch to gvfs on the GNOME side. In addition to that gvfs does not address the problem of making files available transparently to non-GNOME or even non-GUI apps (think vi), or does it? Please either reject it for time reasons and move it to a later version or even better address it for 11, but we should not close and forget about it, as the pain is still there for any user of a desktop that runs at least one major application from the "other side" or from the pre-GUI times. #6: Michael Meeks (michael_meeks) (2008-06-06 12:43:31) (reply to #5) Sure - I want to see this in sled11 too, and we have a plan to investigate this: lets not close it now. #7: Gary Ekker (gekker) (2008-06-09 08:37:43) (reply to #5) GVFS does make files available. At least you can tab-complete a path on a remote host when entering the path for scp for example. #8: Michael Meeks (michael_meeks) (2008-06-09 16:40:05) (reply to #7) Gary: the advantage of switching to a common IO subsystem is that it would make both KDE & Gnome equal peers in terms of their device access: it would also reduce our costs wrt. long term maintainance, and make things far easier for ISVs to integrate with both desktops in one shot. The fact that GVFS works, or KIO works in a given place is not that relevant here :-) + #9: Norbert Frese (nf2) (2009-06-01 02:10:36) + Just to mention it: Here is some experimental work, which tries to + address this problem: + http://live.gnome.org/KioGioBridge + It's not that hard to run KIO on top of GIO/GVFS - but to make it neat, + the dependencies of GVFS need to be approached as well. Particularly + gconf and gnome-keyring. The latter could perhaps be tackled by making + the KDE password manager GUI "dualistic" (allow to peek into both + password managers - KWallet and Keyring daemon). + -- openSUSE Feature: https://features.opensuse.org/120115

1 0