x86-64 rawhide update obnoxiousness

[Michal Jaegermann]

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