[Pkg-fglrx-devel] [RFC] multiarch support for fglrx-driver

[Andreas Beckmann]

On 2011-08-06 21:30, Michael Gilbert wrote:
> Andreas Beckmann wrote:
> 
>> Hi,
>>
>> I'm working on multiarch patches for fglrx-driver. this will require
>> some package splitting to move the libraries into some separate packages
>> that can be Multi-Arch: same.
> 
> Cool!

OK, first trial of multiarch enabled packages ins in SVN: branches/multiarch

It would be nice if someone could actually test them (run X with them,
use 3D, ...), that I can't do easily.

I'll do some upgrade testing with piuparts later on.

>> fglrx-glx will be renamed to libgl1-fglrx-glx (to be in line with
>> libgl1-mesa-glx and libgl1-nvidia-glx), the old name will become a
>> transitional package
> 
> Seems ok to me, but I would prefer for Patrick to make the decision on
> this.

That rename is included in svn, but not mandatory.

>> from fglrx-driver a libfglrx package will be split that contains the
>> libraries (or should that even better be a separate package for each
>> library or at least some of them?) a better name than libfglrx would be
>> welcome.
> 
> fglrx-common?  What does the nvidia package call this?  Why does it
> have to be split?

I had started to use 'nvidia-common' for some utility packages (in
contrib), but soon discovered that Ubuntu has nvidia-common that does
something completely different. These things are now in nvidia-support.
Anyway foobar-common is not a good package name for libraries.

library-wise there is libgl1-nvidia-glx (libGL.so.1, libnvidia-cfg.so.1,
libnvidia-glcore.so.$VERSION, libnvidia-tls.so.$VERSION) for some
libraries that are tightly bundled together, and some more library
packages for a single library each that are mainly independent:
libcuda1, libnvidia-compiler, libnvidia-ml1. Luckily nvidia does not
require X for doing GPGPU stuff, so this splitting could seriously
reduce the package footprint when doing GPGPU only.

I don't know enough about the dependencies between the fglrx libs to
suggest further splitting ... there should be a benefit (i.e. a split
out package is useful on its own and reduces size (and dependencies)
significantly).

>> from fglrx-driver an xserver-xorg-video-fglrx package will be split that
>> contains the xorg modules
> 
> Why is this split needed?

Not really needed (not yet in svn), but use a "common" name so the
package can be more easily found when looking for xserver-xorg-video-*

> So, I guess my question is what about multiarch makes it so that
> fglrx-driver itself can't continue to contain everything?

There are file collisions between fglrx-driver:i386 and
fglrx-driver:amd64, so the libs have to be split out.
The idea is that libfglrx:i386 and libgl1:amd64 can be installed at the
same time without having conflicts, while only one (reduced) variant of
fglrx-driver (:native) can be installed along with them.

>> fglrx-driver will have versioned depends on these 2 new packages
>>
>> is there anything else that should be separated from the fglrx-driver
>> package? e.g. fglrx-utils, libamdxvba-dev, ...
> 
> I'm not sure this is worth the trouble.  The fewer number of packages,
> the better; in my opinion.

Not in my opinion, I like to cut things small :-)

xvba-video currently has a (indirect) Build-Depends: xserver-xorg-core
which is not nice IMHO (nor useful). Therefore I split out libxvbaw-dev,
too :-)

>> There are currently static libraries included in the package. Are they
>> needed for anything useful? Shared libs are available, too.
> 
> I think we're only including shared libs in the binary packages right
> now (except for dkms-modulse which needs a static lib at build time).
> Personally, I don't think the static libs need to be included.

already removed in 11-7-4

Another change I made is to split libfglrx-ia32 from fglrx-glx-ia32,
leaving only libGL.so.1 there. Then I added all missing libs that are
also in libfglrx. While this adds a new -ia32 package that soon will be
obsoleted (but not yet, dpkg in Debian is not yet multiarch enabled), it
will allow me to do some OpenCL testing (with 32-bit apps on amd64) -
libatical*.so are needed for this (and I don't know what other libs).


Andreas