On Wed, Apr 25, 2007 at 07:09:32PM +0200, Patrice Dumas wrote: > On Wed, Apr 25, 2007 at 06:52:21PM +0200, Axel Thimm wrote: > > Consider (*) > > > > yum install foo.i386 > > yum install foo.x86_64 > > yum remove foo.x86_64 > > rpm -V foo > > (same for smart and apt) > > > > The current multilib model in rpm with blindly overwriting files is > > broken by design (e.g. unfixable in shared bindir environments). You > > cannot consider the packaging system a stateless machine anymore. > > Another way of avoiding this issue, however, would be to have > normal conflicts in (/usr)/(s)bin. All the multilib enabled packages > would have to do subpackages without conflicting files and only those > subpackaged could be multilib parallel installable. This is another way > to solve the issue. 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. > It might involve wrapper scripts for executable we really want to be > parallel installable, this issue is indeed better solved with > different (/usr)/(s)bin, but I guess that the number of executables > we want to have in paralell is not a lot. In theory everything. The idea is to not even have to choose what is worth multilibbing or not. That's the paths we've taken until now and that is causing so much administrative overhead. > > Adding to the design issues there are also implementation bugs with > > %docs and %langs that get uninstalled when the i386 package gets > > uninstalled and so on. > > That looks like a bug, not a real issue. The real issue is that these bugs get never fixed. > > Furthermore foo.i386 and foo.x86_64 packages > > often alread conflict on other files which is silently muted during > > coinstallation. > > How is it possible? you mean how does rpm do that, or how do the packages and up having conflicting contents? I just did an RHEL5 full install (we're talking Fedora, but for now I only have these numbers fresh to quote, FC6 will be similar): Momentarily after installing the system I did an rpm -Va and examined the output: It was either 53 or 58 packages that were not verifying due to multilib problems. Just as an example: # rpm -V samba-common .......T /etc/rc.d/init.d/winbind .......T c /etc/samba/lmhosts .......T c /etc/samba/smb.conf .......T /usr/include/libmsrpc.h .......T /usr/include/libsmbclient.h .......T d /usr/share/man/man1/ntlm_auth.1.gz .......T d /usr/share/man/man1/profiles.1.gz .......T d /usr/share/man/man1/smbcquotas.1.gz .......T d /usr/share/man/man1/testparm.1.gz .......T d /usr/share/man/man1/vfstest.1.gz .......T d /usr/share/man/man1/wbinfo.1.gz .......T d /usr/share/man/man5/lmhosts.5.gz .......T d /usr/share/man/man5/smb.conf.5.gz .......T d /usr/share/man/man7/libsmbclient.7.gz .......T d /usr/share/man/man7/pam_winbind.7.gz .......T d /usr/share/man/man8/net.8.gz .......T d /usr/share/man/man8/smbpasswd.8.gz .......T d /usr/share/man/man8/winbindd.8.gz ......G. /var/cache/samba/winbindd_privileged ......G. /var/cache/samba/winbindd_privileged > > It is getting so much convoluted with rpm, yum and anaconda exceptions > > and bug workarounds that we need a clean model. And packaging wise > > this means no more overwriting of files with foreign contents. > > 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. -- Axel.Thimm at ATrpms.net
Attachment:
pgpu5n30YgEXP.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
