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
Attachment:
pgpSYK4rkgRYq.pgp
Description: PGP signature
-- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers
-- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
