Hi, On Tue, Mar 13, 2018 at 03:31:40PM +0100, Florian Weimer wrote: > On 03/13/2018 03:03 PM, Jakub Jelinek wrote: > > The right fix would be to make koji deal with multilibs properly, > > mock can handle that fine already, then glibc32 wouldn't be needed at all. > > I think we requested these feature fifteen years ago, even before there was > Koji. I recently (two months ago) tried to bump the priority, but haven't > heard anything back. It's a pretty fringe use case, and probably needs > major complications within Koji. > > So we need to assume that we'll still need glibc32 going forward. > > The big question, at this point, is what we as packages have to do to > prevent leaking a rebuild into the compose. As far as I understand it, > every package rebuild will trigger this. Build with --skip-tag and file a > releng ticket to have it tagged correctly? I sadly have no idea. > > If that doesn't happen, we need glibc32, but only 0.01% of packages actually > > need it, so e.g. forcing it into every buildroot would be a vaste of time. > > It's actually a bit worse because since it's buildroot-only, we need to > express build requires in such a way that they can be fulfilled by > glibc-devel.i686. Otherwise, people would not be able to rebuild these > packages using mock. Yeah, the current way to pull things in that works everywhere seems to be to do use file based requires like /usr/lib/libc.so because otherwise things break in koji. I always assumed koji was just a mock running in "the cloud", but I assume it is slightly more involved than that. Cheers, Mark _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
