Re: multiarch status update
Darren Salt <linux@youmustbejoking.demon.co.uk> writes:
> I demand that Gabor Gombas may or may not have written...
>
> [snip]
>> How do you want to handle one-arch-only binNMUs? binNMUs change
>> changelog.Debian.gz, so
>> - you can't upgrade just the architecture that was binNMUed without
>> changelog.Debian.gz becoming invalid for the other arches
> [snip]
>
> I think that this'll just have to be accepted - ignore the binNMU versioning
> when comparing versions for co-installation, but take the docs from the
> highest-numbered binNMU.
>
> I don't know how a binNMU for one architecture followed by a binNMU for
> another is handled, but it seems reasonable to me that the newer one will
> have to include the changelog from the older one and, therefore, must have a
> higher version number. Otherwise, which binNMU changelog entry you get is a
> matter of chance, and entries may even be lost in later uploads.
Not to mention that binNMU for only one arch will be fixing a build
screwup like a broken gcc version on that arch causing faulty
binaries. And binNMUs for multiple/all archs will be to help
transitions in their depends along.
In both cases no change has been made to the source and the reason for
the binNMU is quite irelevant to most users.
But there will be times where the actual source version of debs for
each arch differs. Actualy at every upgarde that happens between arch1
getting unpacked and arch2 getting unpacked as well. Dpkg just has to
handle it in some sane way.
MfG
Goswin
Reply to: