On Mon, 17 Oct 2005, Michal Jaegermann wrote:
Things do change and not always only in a revision number. If you are grabbing everything from a given directory then in '%files' section you may have a line like
/some/dir/files/*
and you are ok. If you start explicitely splitting that then you need to be more specific and with every release you need check all of this and every mistake in that process means a new update and complaints all over the place that yum failed again.
Hmm, I don't see why that would be so really.
- rpmbuild will complain about unpackaged files (indeed, it's now an error - no rpm at all).
- Files already listed are unlikely to change their type all of a sudden.
- Even easier (if multi-arch in one package were possible) Rpmbuild could potentially just automatically check the arch of files when packaging and annotate the files accordingly (it already examines files to work out dependencies)
- The common case for 'overlap' files is documentation, these have been annotated with %doc in spec files for a long time (and hence could automatically be hived off to a noarch package by rpmbuild..)
- Really, from experience, this just isn't that difficult to maintain. Enumerating build dependencies and unobvious dependencies takes far more effort when maintaining spec files, particularly if you want a spec file to work across multiple releases of a distro.
(But, I only maintain a spec file for one package, so maybe I just don't add/remove files from this package often enough..)
That is simple. Assume that you have installed packages
package-bin-1.0.0-1.i386 package-bin-1.0.0-1.x86_64 package-common-1.0.0-1.noarch
Both "bin" packages depend on 'package-common-<right_version>'. They have to. Now you try to update to package-bin-1.0.0-2.x86_64 without touching package-bin.i386. That immediately pulls in package-common-1.0.0-2.noarch. Boom! Failed dependencies!
Of course, and this case is no different from the case of dependency chains on single-arch only.
Different problem, solution is "use yum" - it works out the dependencies.
What you gained above is that removing package-bin.i386 will not mess up anything in package-common.noarch. So for a huge effort you are a small bit ahead but not far enough.
It'd be a huge effort yes, but it *would* solve it.
The other alternative is multiple-arch packages, with arch-dependent files annotated or sectioned in some way (as IRIX did it, and IRIX had not 2 but 3 different ABIs ;) - worked well, but the packages are obviously bigger).
Another possibility: Reference count the files. Last package uninstalled removes the file. But that doesnt allow higher-level package management systems to spot such dependencies though.
regards,