[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl)



On Thu, Apr 26, 2007 at 10:16:58AM +0200, Axel Thimm wrote:
> On Thu, Apr 26, 2007 at 09:29:23AM +0200, Patrice Dumas wrote:
> > 
> > But it will end up, on x86_64 with the binaries for the primary arch not
> > to be in the classical paths. Wouldn't it better to have
> > _bindir=/usr/bin32 for 32 bit apps?
> 
> No, because you want to reuse the packages from i386 that will already
> occupy /usr/bin. /usr/bin32 for i386 would imply that
> 
> o either all packages in i386 are rebuilt for i386 to place their bins
>   there, too, and then your argument of not a classical path would
>   apply to all i386 system, which outweigh the x86_64 ones, or

This is clearly out of question.

> o You have different i386 packages for i386 and x86_64, which is also
>   not a good solution, because you lose the QA for the pure i386
>   packages.

In my opinion having preferred arch binaries not in *bin/ is also not very
clean in my opinion. I personally think that I'd prefer to have the
preferred arch binaries in *bin/ and therefore different builds on
i386 and x86_64 for 32 bit packages. This is debatable, since it implies
a change in the build infrastructure, another repo for i386 on x86_64.

I think that it should be nice if there was a consensus on that
multiarch idea, but I also think that we shouldn't rush to a specific
solution, in the mean time we should try to have a multilib system
without conflicts.

> mtime doesn't create conflicts AFAIK, it is just visibly in rpm
> --verify. But ideally, as you say, the packages should be fixed to
> have proper timestamps, and see above for a way on how to deal with
> the problem of generated documentation.

You mean above in the thread? I missed it, but I'll search.

--
Pat


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]