[Pkg-fglrx-devel] Bug #740843 apt: fails to upgrade the fglrx family of packages with multiarch

[Simon McVittie]

On 05/03/14 14:27, Simon McVittie wrote:
> The test set of packages are created by the attached files (put them all
> in the same directory and run make), and are a simplified version of the
> original situation involving fglrx:
> 
>     foo-driver amd64 installed
>         Depends: libfoo (= VERSION)
>         Recommends: libgl1-foo-glx (= VERSION)
>         Breaks: libgl1-foo-glx (<< VERSION)
>         Breaks: libgl1-foo-glx (>> VERSION)

When I simplify the newer version to

    foo-driver
        Depends: libfoo (= 2), libgl1-foo-glx (= 2)

the upgrade works fine; that provides a likely workaround that could be
applied to fglrx-driver.

Looking at the svn history of fglrx-driver, it seems it was a Depends
until recently, but was demoted to a Recommends + Breaks because in
principle you might only want fglrx-driver:amd64 and
libgl1-fglrx-glx:i386, which wouldn't otherwise satisfy the dependency.
That seems a pretty tenuous reason: fglrx-driver maintainers, would
there be anything wrong with bumping it back up to a Depends and
simplifying the dependency graph?

This perhaps also suggests what the apt bug is: is there some special
case for lockstep dependencies containing Depends that isn't triggered
by bidirectional Breaks?

If you really don't want the Depends, moving the Breaks around also
seems to work:

    foo-driver
        Depends: libfoo (= 2)
        Breaks: libgl1-foo-glx (<< 2)

    libgl1-foo-glx
        Depends: libfoo (= 2)
        Breaks: foo-driver (<< 2)

resulting in

> dpkg: considering deconfiguration of foo-driver, which would be
> broken by installation of libgl1-foo-glx:amd64 ...
> dpkg: yes, will deconfigure foo-driver (broken by
> libgl1-foo-glx:amd64)
> (Reading database ... 15596 files and directories currently
> installed.)
> Preparing to replace libgl1-foo-glx:amd64 1 (using
> .../foo/libgl1-foo-glx_2_amd64.deb) ...
> De-configuring foo-driver ...
> De-configuring libgl1-foo-glx:i386 ...
> Unpacking replacement libgl1-foo-glx:amd64 ...

which might also point someone who knows more about apt than I do
towards a relevant apt bug?

Or is this considered by the apt maintainers to be a packaging bug?

Thanks,
    S