On Mon, Oct 17, 2005 at 06:01:13PM +0100, Paul Jakma wrote: > On Mon, 17 Oct 2005, Michal Jaegermann wrote: > > >coming from different places you do not always control, and keeping > >these specs _correct_, i.e. no forgetfulness, mistakes, ignorance, > >etc, for all future revisions. > > How so? You can generate all the required packages from one spec > file. 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. > > >The problem which started all this thread, i.e. "asynchronous > >updates" causing conflict complaints, in no way will be helped by a > >split you envision. > > I'm not sure how you reach that conclusion. 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! This is not even spurious as there are no guarantees that files in package-common-1.0.0-1.noarch and package-common-1.0.0-2.noarch are the same and if you will will go to package-common-1.1.0-1.noarch then you _know_ that they are different because at least this is the case for %doc directory. If you will try to force installing both package-common-1.0.0-1.noarch and package-common-1.0.0-2.noarch then you have collisions. Back to the square one. 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. Michal -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list