Re: [Bug 563] Review request: xorg-x11-drv-catalyst - AMD's proprietary driver for ATI graphic cards

http://bugzilla.rpmfusion.org/show_bug.cgi?id=563 --- Comment #4 from Stewart Adam <s.adam(a)diffingo.com&gt; 2009-04-21 21:16:26 --- BTW - For those who are looking at the bug and want to know what kwizart and I mean by old/new scheme, "old scheme" refers to the current setup with livna-config-display where all configuration files are simply included in the driver packages. "New scheme" refers to a future setup with rpmfusion-config-display where configuration files are generated on-demand, making driver switches much easier. (In reply to comment #3) > 1* Does this file remains needed with 9.4? (should be set as %config at least) > %{_sysconfdir}/udev/makedev.d/40-catalyst-dri.nodes > (in other words, Is the module capable to create it own devices on > /dev/dri/card? ) > the file need to be removed "then" the initrd regenerated in order to test for > this feature. Will test at home tonight. > This problem itself is a blocker for later improvement of the packaging scheme > of the binary GPU drivers. Now this is not a problem as we will stay with the > previous scheme until this is solved. I saw in the last git commit you made from rpmfusion-config-display you added a structure so we could create/destroy these files using r-c-d... I will try to continue working on this soon, and if it works then the need for files like the blacklist, udev configuration or power scripts will no longer be a problem. > In general we need to check if every file remains necessary. +1 > 3* -devel subpackage > %{atilibdir}/*.a > %{_libdir}/xorg/modules/*.a > %{_includedir}/GL/ > %{_includedir}/X11/extensions/*.h > Theses files conflict with mesa-ones, the nVidia driver have them installed in > /usr/include/nvidia which the package should have them installed probably in > /usr/include/catalyst. That needs to be changed with the package converted to > the new scheme. > This could be dropped as a consequence: > Requires: %{_includedir}/X11/extensions, %{_includedir}/GL Will fix + test compiling software against the relocated headers tonight as well. > 4* ||: or everyline with scriplets. > This tweak is aimed to avoid error that might prevents rpm transaction if ever > the scriptlet failed for any reason. That's prevent package to fail to > install/uninstall, so it only make sense at the end (un-conditional) of a > scriplet. Done > 5* %postun -p /sbin/ldconfig > ^^ This is uneeded, (read evil) as the main package doesn't provide any system > wide shared objects,that need to be registered with ldconfig. (only xorg > libraries that are meant to be dlopened). Done > 6* Missing conflicts : > Conflicts: xorg-x11-drv-nvidia-71xx (legacy new name supposed to be > re-introduced at a later time once nVidia support new xorg-server). > Conflicts: xorg-x11-drv-nvidia-custom Done > 7* deprecated Obsoletes/Provides from fglrx package history: > This doesn't have to be introduced in the new package (could be dropped in > fglrx also actually.) > Obsoletes: ati-x11-drv < %{version}-%{release} > Provides: ati-x11-drv = %{version}-%{release} > ... > Obsoletes: ati-x11-drv-devel < %{version}-%{release} > Provides: ati-x11-drv-devel = %{version}-%{release} > ... If we get rid of these, then FreshRPM users who install RPM Fusion will have no upgrade path... If we no longer wish to support this upgrade path on new branches (ie, F-11), I'm OK with that but I think that we need to keep it for F-9/F-10. > %ifarch %{ix86} > Provides: %{name}-libs-32bit = %{version}-%{release} > Obsoletes: %{name}-libs-32bit <= %{version}-%{release} > %endif > ... > Requires: %{atilibdir}/libGL.so.1.2 > ^^ this one is not needed along with the use of > Requires: %{name}-libs-%{_target_cpu} = %{version}-%{release} > (for the main package) Fixed > 8* %config need to be appended for earch file using /etc > There is a need to verify if this is still relevant for some files that may > even not be relevant to have in /etc but where ati/amd uses some hardcoded path > which prevent us to use that. Done > So to sum-up , I expect this package to be introduced in F-10/F-11 (F-9?). F-10 and F-11 right away (will migrate from old to new scheme eventually), and F-9 afterwards (but kept at the old scheme). > Most of the above notes at pretty trivial to fix. (since that's just few tweaks > from a fglrx->catalyst rename) But I note this is for the old scheme. I really > think we need to work on the new scheme for both F-10/F-11. +1 - this is partially my fault, I don't have much time... I'm finishing the semester mid-may, at that point I'll have much more time to finish the last bits of r-c-d. -- 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.