x86-64 rawhide update obnoxiousness

[Paul Jakma]

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 at clubi.ie	paul at jakma.org	Key ID: 64A2FF6A
Fortune:
Where there are visible vapors, having their prevenance in ignited
carbonaceous materials, there is conflagration.