[Bug 171] Review Request: rpmfusion-config-display - tool to manage proprietary graphic drivers

[RPM Fusion Bugzilla]

http://bugzilla.rpmfusion.org/show_bug.cgi?id=171





--- Comment #51 from Stewart Adam <s.adam at diffingo.com>  2009-02-23 21:52:54 ---
(In reply to comment #49)
> Either we pick both /usr/share/rpmfusion-config-display/config and
> /etc/rpmfusion-config-display.d to store the official configuration files.
> Either just /etc/rpmfusion-config-display.d. But the files are aimed to be
> customizeable by users, so it will eventually be better to keep only one
> directory to avoid namespace issue with different directory rules.
> Also it is important that only the files ending with .conf to be processed, so
> backup files from edition (*~) will not be taken into account. Our own
> "official" config files are meant to be set as %config and can get potentially
> replaced at each update.
Good call - I'll make the config files use a '.conf' suffix and this will be
stripped when parsing the files so we have the same trick where the filename is
used to determine the GL library and Xorg extension file locations.
> At this time, the tool in not ready for inclusion for few reasons:
> - We need to froze the config FILES. (xvmc, avoid duplicate info, double
> choices for modules)
I've done XvMC locally, will include in next update... What is the duplicate
info we should remove?
> - The tool need to be updated with the lastest scheme for replacement_xorg_libs
> that could lead to avoid the needs of tweaking xorg.conf at all with F-10 and
> beyond.
I haven't heard of this - is there a Wiki page I can read up about it?
> - We need to figure out about what to do with the vendor configuration tools
> (multiple version shipped, only open sources ones for nvidia, allow to edit,
> will they appear if the other vendor driver is activated).
IMO: Let's stop packaging those in /usr/bin and put them somewhere else
instead. We can put our own generic wrapper in /usr/bin for the CLI tools, and
have the appropriate GUI tool (amdccle or nvidia-settings) launch from a button
inside the rpmfusion-config-display GUI.
> - Tweaks for mesa-libGL removal for bogus application that want to dlopen
> libGL.so.1 from the standard places.
The programming for this is done already and can be activated with the hidden
options --libgl-symlink-hack and --undo-libgl-symlink-hack. We can make those
options more exposed if needed, but I think leaving things as is and putting a
note in README is sufficient... We don't want users playing around with that
unless absolutely needed.

(In reply to comment #50)
> Why do they need to be customizeable? 
One of the main goals I had in mind while designing rpmfusion-config-display
was that it should be completely extendable - this way, users who prefer to use
the foo.run packages or even 3rd (4th?) parties could use
rpmfusion-config-display as the configuration system. 
> Further: When you put them in /etc only and make them customizable then users
> will have to merge .rpmnew-files into the real config files on each update.
> That is a PITA and will result in a lot of confusion and breakage. 
> IOW: that way lie big dangerous dragons. Don't go there. ;-)
While that's true, at the same time that is the desired behavior - users
shouldn't be modifying our files in-place, but creating a copy of them. If they
do modify our files in-place, then RPM will renamed their modified file and
replace it with our packaged one.


-- 
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.