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

[RPM Fusion Bugzilla]

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





--- Comment #4 from Stewart Adam <s.adam at diffingo.com>  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.