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,
--
Paul Jakma paul@xxxxxxxx paul@xxxxxxxxx Key ID: 64A2FF6A
Fortune:
Where there are visible vapors, having their prevenance in ignited
carbonaceous materials, there is conflagration.
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list