Merging multilib toolchain with [core]

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Merging multilib toolchain with [core]

Bartłomiej Piotrowski-3
Hi,

For a long time we have been maintaining multilib-enabled gcc package
separately under [multilib] repo. Compilation takes a lot and usually it
falls behind because I forget to keep it in sync with [core].

I propose to merge it with core/gcc instead and split lib32-gcc-libs.
The latter would be moved to [core] due to dbscripts inability to
maintain split packages in multiple repositories. On the same note, the
same would happen to lib32-glibc.

Any objections?
Bartłomiej
Reply | Threaded
Open this post in threaded view
|

Re: Merging multilib toolchain with [core]

arch dev mailing list
Le mercredi 22 novembre 2017, 12:19:12 CET Bartłomiej Piotrowski a écrit :

> Hi,
>
> For a long time we have been maintaining multilib-enabled gcc package
> separately under [multilib] repo. Compilation takes a lot and usually it
> falls behind because I forget to keep it in sync with [core].
>
> I propose to merge it with core/gcc instead and split lib32-gcc-libs.
> The latter would be moved to [core] due to dbscripts inability to
> maintain split packages in multiple repositories. On the same note, the
> same would happen to lib32-glibc.
>
> Any objections?
> Bartłomiej
It's a good idea.

--
Laurent Carlier
http://www.archlinux.org

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Merging multilib toolchain with [core]

arch dev mailing list
In reply to this post by Bartłomiej Piotrowski-3
Quoting Bartłomiej Piotrowski (2017-11-22 12:19:12)

> Hi,
>
> For a long time we have been maintaining multilib-enabled gcc package
> separately under [multilib] repo. Compilation takes a lot and usually it
> falls behind because I forget to keep it in sync with [core].
>
> I propose to merge it with core/gcc instead and split lib32-gcc-libs.
> The latter would be moved to [core] due to dbscripts inability to
> maintain split packages in multiple repositories. On the same note, the
> same would happen to lib32-glibc.
>
> Any objections?
> Bartłomiej
I'm definitely in favour of it, and have had some issues quite a few
times with automatic package building and having pacman automatically
replace gcc with gcc-multilib.

To work around it with the new reproducibility builds that are currently
running we chose to work around it by just explicitly specifying all of
the multilib-devel packages and then piping `yes` into pacman.

(Side note:  It would be nice if there was a handy way to say yes to all
group members programmatically and also accepting any replaces.  Since
the two prompts requires different input, it would currently require
some hacky `echo` sequences into pacman, hm.)

--
Sincerely,
  Johannes Löthberg
  PGP Key ID: 0x50FB9B273A9D0BB5
  PGP Key FP: 5134 EF9E AF65 F95B 6BB1  608E 50FB 9B27 3A9D 0BB5
  https://theos.kyriasis.com/~kyrias/

signature.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Merging multilib toolchain with [core]

Allan McRae
In reply to this post by Bartłomiej Piotrowski-3
On 22/11/17 21:19, Bartłomiej Piotrowski wrote:

> Hi,
>
> For a long time we have been maintaining multilib-enabled gcc package
> separately under [multilib] repo. Compilation takes a lot and usually it
> falls behind because I forget to keep it in sync with [core].
>
> I propose to merge it with core/gcc instead and split lib32-gcc-libs.
> The latter would be moved to [core] due to dbscripts inability to
> maintain split packages in multiple repositories. On the same note, the
> same would happen to lib32-glibc.
>

I was planning this for once i686 was dropped.  So good to see it happening!

A