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

[Axel Thimm]

On Thu, Apr 26, 2007 at 09:29:23AM +0200, Patrice Dumas wrote:
> On Wed, Apr 25, 2007 at 07:39:42PM +0200, Axel Thimm wrote:
> > 
> > Yes, but it does involve much more work to do. And if we assume that
> > every package is in principle candidate for multilib, we would end
> > with a guidelines to have all packages using bindir to split off
> > subpackages. The setting _bindir=/usr/bin64 would already fix the
> > majority of packages w/o having to touhc the specfile.
> 
> 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

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.

> > > Except if they have the same md5 sum?
> > 
> > Yes and no. One can discuss the usefulness of mtime verification (I
> > personally think it is useful, and I think the packages can be made to
> > have the same timestamps on both archs, just use install -p and for
> > generated files use touch -r from the master files), but there is far
> > more important metadata like owner/group and mode of the files that
> > should never be ignored and allowed to conflict.
> 
> I agree that diferent owner/group and mode of the files should trigger
> a conflict. For timestamps it is a goal for packaging to keep them and
> have them identical on both arches, but I don't think it should create a
> conflict at install time. Some are not easy to avoid, like build time
> generated documentation.

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.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-maintainers/attachments/20070426/c5bf7ff2/attachment.sig>