Thomas Steffen wrote: > The better way to do it is to have three (sub)packages: i386, x86_64 > and shared. That is a bit like -common and -bin, but the packages > differ only in architecture, not in the name. Imho that is the way to > go. > > However, if you look closer, you find that both approaches impose the > same restrictions: all two or three (sub)packages have to be exactly > the same version, they have to match. So you can't upgrade one without > upgrading the other(s). That all depends on if the relationship is == or >=. It shouldn't if it is a >= dependency. But I am not sure that is practical for /usr/share files in general. But splitting that many packages would certainly increase the number of descrete packages hugely. > I think this severely limits the ability to install third-party i386 > software on a RedHat x86_64 system. As soon as the third-party > software requires a library upgrade, you get conflicts. (Now that > problem isn't new either, it is the reason behind DLL hell...) But wait, most people who install RH systems don't actually ever upgrade. At the time they put the install cdrom in the box they install everything because they have been taught by experience that upgrades later don't work, better grab it now. So if they go to install something later it needs a newer library they consider that application completely unsupported on version X and think "I need to reinstall the system from scratch to get to version Y so that this application will run", no matter how trivial the requirement. Bob
Attachment:
signature.asc
Description: Digital signature