[arch-dev-public] mesa packaging, libGL handling
teg at jklm.no
Fri Feb 15 08:01:59 EST 2013
On Fri, Feb 15, 2013 at 1:07 PM, Jan de Groot <jan at jgc.homeip.net> wrote:
> At this moment our Mesa package is a mess. It contains several split
> packages, some even just containing one file. Most of these packages
> depend on eachother, so other than "let's make it look like Debian" I
> don't see a big need for splitups anymore.
> The initial splitup was *-dri due to its size, libgl due to nvidia-utils
> replacing it and mesa for the rest of the package. I would propse a
> different structure: one single mesa package which doesn't ship
> libGL.so.1 and libGL.so symlinks.
> These symlinks should be removed from other packages as well and should
> get placed in post_install/post_upgrade. In case of nvidia-utils and
> catalyst it should replace them, in case of mesa it should only place
> them if they don't exist or point to nonexistent files.
> On post_remove the symlinks should get removed in case they link to
> nonexistent files (mesa) or reverted to libGL.so from mesa if that is
> still installed (nvidia, catalyst).
> This should make the PKGBUILD a lot more readable and should improve our
> situation with (make)dependencies at the cost of some extra
> driver/library/header bloatware that gets installed in case you need
> libGL for something.
> An additional downside of this implementation is that namcap doesn't
> know where libGL.so.1 comes from, resulting in "depends on uninstalled
> dependency libGL.so.1".
> What do other developers think about this approach?
I was just looking at mesa a few days ago, and agree that it should be merged.
I'm not a huge fan of post_* magic, though. Could we perhaps avoid
this by putting the symlinks in a separate package 'libgl'?
I suppose the structure should be that libgl would pull in mesa; and
nvidia and friends would also pull in mesa but
replace/conflict/provide libgl? I might have gotten this slightly
wrong as I don't know mesa too well, but I think something along these
lines should work...
More information about the arch-dev-public