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

[Michael Gilbert]

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!

> 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.

> 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?

> from fglrx-driver an xserver-xorg-video-fglrx package will be split that
> contains the xorg modules

Why is this split needed?

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

> 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.
 
> 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.

> Splitting packages means a DD upload is required and the package will
> make a trip through the NEW queue, which might take some time. And we
> should probably target experimental first.

Agreed.  Would you be interested in starting an experimental branch in
svn for this?

Best wishes,
Mike