[arch-multilib] gcc-libs-multilib should not replace gcc-libs
Hi all, I just noticed that gcc-libs-multilib replaces and provides gcc-libs. I would prefer if this package would just provide those files in /usr/lib32 and not replace a core package. The disadvantages of the current package are that systems might break if gcc in core/testing is newer and its more difficult to remove the multilib packages. I see that this is a bigger problem for gcc itself; but this wont be installed by the average user anyway and only in the build chroot. So my suggestion would be that multilib (runtime) packages should not replace packages from core or extra. Greetings, Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre
On 08/27/10 02:38, Pierre Schmitz wrote:
...I see that this is a bigger problem for gcc itself; but this wont be installed by the average user anyway and only in the build chroot.
The average *Arch* user, though, may well install gcc. (Do we have package-usage-statistics? I thought maybe yes but Google didn't show me where.) Especially if they install anything from AUR. Not sure whether this figures into the multilib-engineering-decisions any particular way -- but thought I'd mention it. -Isaac
On Fri, 27 Aug 2010 02:51:37 -0400, Isaac Dupree
On 08/27/10 02:38, Pierre Schmitz wrote:
...I see that this is a bigger problem for gcc itself; but this wont be installed by the average user anyway and only in the build chroot.
The average *Arch* user, though, may well install gcc. (Do we have package-usage-statistics? I thought maybe yes but Google didn't show me where.)
Especially if they install anything from AUR.
Not sure whether this figures into the multilib-engineering-decisions any particular way -- but thought I'd mention it.
-Isaac
I was talking about the gcc-multilib not the gcc from [core]. -- Pierre Schmitz, https://users.archlinux.de/~pierre
Am 27.08.2010 08:38, schrieb Pierre Schmitz:
Hi all,
I just noticed that gcc-libs-multilib replaces and provides gcc-libs. I would prefer if this package would just provide those files in /usr/lib32 and not replace a core package.
There is no replaces tag.
The disadvantages of the current package are that systems might break if gcc in core/testing is newer and its more difficult to remove the multilib packages. I see that this is a bigger problem for gcc itself; but this wont be installed by the average user anyway and only in the build chroot.
Looks difficult and inconsistent to me. We might consider it though.
Am Fri, 27 Aug 2010 12:48:55 +0200
schrieb Thomas Bächler
Am 27.08.2010 08:38, schrieb Pierre Schmitz:
Hi all,
I just noticed that gcc-libs-multilib replaces and provides gcc-libs. I would prefer if this package would just provide those files in /usr/lib32 and not replace a core package.
There is no replaces tag.
But there's a conflicts=('gcc-libs') in gcc-libs-multilib's PKGBUILD. I, too, would prefer a lib32-gcc-libs package which is installed additionally to and doesn't replace gcc-libs from [core]. Heiko
On Fri, Aug 27, 2010 at 8:38 AM, Pierre Schmitz
Hi all,
I just noticed that gcc-libs-multilib replaces and provides gcc-libs. I would prefer if this package would just provide those files in /usr/lib32 and not replace a core package. The disadvantages of the current package are that systems might break if gcc in core/testing is newer and its more difficult to remove the multilib packages. I see that this is a bigger problem for gcc itself; but this wont be installed by the average user anyway and only in the build chroot.
So my suggestion would be that multilib (runtime) packages should not replace packages from core or extra.
Greetings,
Pierre
I will be splitting lib32-gcc-libs from gcc-multilib. All lib32-packages should depend on this instead of gcc-libs-multilib. I'll fix these: |--gcc-libs-multilib |--lib32-mesa |--lib32-pcre |--lib32-db |--gcc-multilib |--lib32-gnutls |--nspluginwrapper |--lib32-flac Are there any left?
participants (5)
-
Heiko Baums
-
Isaac Dupree
-
Jan Steffens
-
Pierre Schmitz
-
Thomas Bächler