[arch-dev-public] mesa packaging, libGL handling
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?
On Fri, Feb 15, 2013 at 1:07 PM, Jan de Groot <jan@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... Cheers, Tom
Am 15.02.2013 14:01, schrieb Tom Gundersen:
I'm not a huge fan of post_* magic, though. Could we perhaps avoid this by putting the symlinks in a separate package 'libgl'?
+1 for only having the symlinks split out. This should still simplify the installation greatly.
On 15.02.2013 16:01, Thomas Bächler wrote:
Am 15.02.2013 14:01, schrieb Tom Gundersen:
I'm not a huge fan of post_* magic, though. Could we perhaps avoid this by putting the symlinks in a separate package 'libgl'?
+1 for only having the symlinks split out. This should still simplify the installation greatly.
+1 for splitting those into a package Creating files in the install script is too fragile and a small package with just 2 symlinks doesn't result in a hard-to-read PKGBUILD.
On 15/02/13 22:07, Jan de Groot 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?
-1 to having untracked files in /usr/lib
Am 15.02.2013 16:00, schrieb Allan McRae:
On 15/02/13 22:07, Jan de Groot wrote:
What do other developers think about this approach?
-1 to having untracked files in /usr/lib
I have to agree with Allan here. Untracked files are bad and we have regretted using these in the past. It always ended up with "user interaction needed" update announcements. Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com
Le vendredi 15 février 2013 13:07:01 Jan de Groot a écrit :
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?
Perhaps we could merge: - mesa, khrplatform-devel - libglapi, libgl, libgles - libgbm, libegl
On Fri, Feb 15, 2013 at 5:10 PM, Laurent Carlier <lordheavym@gmail.com> wrote:
Perhaps we could merge: - mesa, khrplatform-devel - libglapi, libgl, libgles - libgbm, libegl
Also, the pipe drivers from libgbm should be sorted into the *-dri packages.
On Fri, Feb 15, 2013 at 7:05 PM, Jan Steffens <jan.steffens@gmail.com> wrote:
On Fri, Feb 15, 2013 at 5:10 PM, Laurent Carlier <lordheavym@gmail.com> wrote:
Perhaps we could merge: - mesa, khrplatform-devel - libglapi, libgl, libgles - libgbm, libegl
Also, the pipe drivers from libgbm should be sorted into the *-dri packages.
Out of curiosity, what would be the benefit of keeping it split up rather than just merging (almost) everything? -t
On Fri, Feb 15, 2013 at 8:02 PM, Tom Gundersen <teg@jklm.no> wrote:
Out of curiosity, what would be the benefit of keeping it split up rather than just merging (almost) everything?
The drivers are damn large (thanks to LLVM). No need to have them installed if you ain't got the hardware.
On 15.02.2013 20:15, Jan Steffens wrote:
On Fri, Feb 15, 2013 at 8:02 PM, Tom Gundersen <teg@jklm.no> wrote:
Out of curiosity, what would be the benefit of keeping it split up rather than just merging (almost) everything? The drivers are damn large (thanks to LLVM). No need to have them installed if you ain't got the hardware. Can't you build them with shared llvm libs?
Le vendredi 15 février 2013 20:16:57 Sven-Hendrik Haase a écrit :
On 15.02.2013 20:15, Jan Steffens wrote:
On Fri, Feb 15, 2013 at 8:02 PM, Tom Gundersen <teg@jklm.no> wrote:
Out of curiosity, what would be the benefit of keeping it split up rather than just merging (almost) everything?
The drivers are damn large (thanks to LLVM). No need to have them installed if you ain't got the hardware.
Can't you build them with shared llvm libs?
Currently it's not really possible, because mesa>9.0.2+ and <9.2/10.0 uses a different llvm (from Tom Stellar), 9.2/10.0 will use llvm 3.3 so using shared library should be faisable more easily.
On Fri, Feb 15, 2013 at 8:16 PM, Sven-Hendrik Haase <sh@lutzhaase.com> wrote:
Can't you build them with shared llvm libs?
Nope, we don't have any. Building LLVM with cmake instead of autotools creates them, but that approach has other problems.
Le vendredi 15 février 2013 20:02:28 Tom Gundersen a écrit :
On Fri, Feb 15, 2013 at 7:05 PM, Jan Steffens <jan.steffens@gmail.com> wrote:
On Fri, Feb 15, 2013 at 5:10 PM, Laurent Carlier <lordheavym@gmail.com> wrote:
Perhaps we could merge: - mesa, khrplatform-devel - libglapi, libgl, libgles - libgbm, libegl
Also, the pipe drivers from libgbm should be sorted into the *-dri packages. Out of curiosity, what would be the benefit of keeping it split up rather than just merging (almost) everything?
-t
Just asked on irc, libegl can only work with mesa, not with nvidia/ati blobs. So a merge between libglapi, libgl, libgles, libgbm and libegl make sense.
Am Fri, 15 Feb 2013 20:17:03 +0100 schrieb Laurent Carlier <lordheavym@gmail.com>:
Le vendredi 15 février 2013 20:02:28 Tom Gundersen a écrit :
On Fri, Feb 15, 2013 at 7:05 PM, Jan Steffens <jan.steffens@gmail.com> wrote:
On Fri, Feb 15, 2013 at 5:10 PM, Laurent Carlier <lordheavym@gmail.com> wrote:
Perhaps we could merge: - mesa, khrplatform-devel - libglapi, libgl, libgles - libgbm, libegl
Also, the pipe drivers from libgbm should be sorted into the *-dri packages. Out of curiosity, what would be the benefit of keeping it split up rather than just merging (almost) everything?
-t
Just asked on irc, libegl can only work with mesa, not with nvidia/ati blobs. So a merge between libglapi, libgl, libgles, libgbm and libegl make sense.
My current plan: merge libglapi mesa osmesa libgbm libgles libegl khrplatform-devel and a separate libgl with libGL.so and libglx.so conflicting with nvidia-utils. Not sure if we can do this without symlinks. I'd like to keep separate *-dri driver packages. Nobody needs drivers for other hardware. -Andy
My current plan: merge libglapi mesa osmesa libgbm libgles libegl khrplatform-devel and a separate libgl with libGL.so and libglx.so conflicting with nvidia-utils. Not sure if we can do this without symlinks.
I'd like to keep separate *-dri driver packages. Nobody needs drivers for other hardware.
-Andy
I've updated the Mesa PKGBUILD in trunk. Please have a look if it now covers all your wishes. Mesa 9.1 release is expected for this Friday. We will need an updated llvm-amdgpu-snapshot pkg to be able build all AMD drivers. -Andy
Le mardi 19 février 2013 20:34:36 Andreas Radke a écrit :
My current plan: merge libglapi mesa osmesa libgbm libgles libegl khrplatform-devel and a separate libgl with libGL.so and libglx.so conflicting with nvidia-utils. Not sure if we can do this without symlinks.
I'd like to keep separate *-dri driver packages. Nobody needs drivers for other hardware.
-Andy
I've updated the Mesa PKGBUILD in trunk. Please have a look if it now covers all your wishes.
Mesa 9.1 release is expected for this Friday. We will need an updated llvm-amdgpu-snapshot pkg to be able build all AMD drivers.
-Andy
An update for llvm-amdgpu-snapshot will follow soon in community-testing ++
Le mardi 19 février 2013 20:34:36 Andreas Radke a écrit :
My current plan: merge libglapi mesa osmesa libgbm libgles libegl khrplatform-devel and a separate libgl with libGL.so and libglx.so conflicting with nvidia-utils. Not sure if we can do this without symlinks.
I'd like to keep separate *-dri driver packages. Nobody needs drivers for other hardware.
-Andy
I've updated the Mesa PKGBUILD in trunk. Please have a look if it now covers all your wishes.
Mesa 9.1 release is expected for this Friday. We will need an updated llvm-amdgpu-snapshot pkg to be able build all AMD drivers.
-Andy
Some comments about the new mesa packages: - Remove mesa-libgl.so and mesa-libgl.so.1, they are useless, only create symlinks like libgl.so -> libgl.so.1 -> mesa-libgl.so.1.2 - Perhaps rename mesa-libgl into mesa-utils for consistency with nvidia-utils and catalyst-utils ? ++
On 02/21/2013 04:08 PM, Laurent Carlier wrote:
Le mardi 19 février 2013 20:34:36 Andreas Radke a écrit :
My current plan: merge libglapi mesa osmesa libgbm libgles libegl khrplatform-devel and a separate libgl with libGL.so and libglx.so conflicting with nvidia-utils. Not sure if we can do this without symlinks.
I'd like to keep separate *-dri driver packages. Nobody needs drivers for other hardware.
-Andy
I've updated the Mesa PKGBUILD in trunk. Please have a look if it now covers all your wishes.
Mesa 9.1 release is expected for this Friday. We will need an updated llvm-amdgpu-snapshot pkg to be able build all AMD drivers.
-Andy
Some comments about the new mesa packages: - Remove mesa-libgl.so and mesa-libgl.so.1, they are useless, only create symlinks like libgl.so -> libgl.so.1 -> mesa-libgl.so.1.2 - Perhaps rename mesa-libgl into mesa-utils for consistency with nvidia-utils and catalyst-utils ?
-1 nvidia-utils contains a lot of crap apart of libgl. mesa-libgl sounds fine .
++
-- Ionuț
participants (11)
-
Allan McRae
-
Andreas Radke
-
Florian Pritz
-
Ionut Biru
-
Jan de Groot
-
Jan Steffens
-
Laurent Carlier
-
Pierre Schmitz
-
Sven-Hendrik Haase
-
Thomas Bächler
-
Tom Gundersen