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

[Simon McVittie]

On 07/03/14 00:37, David Kalnischkies wrote:
> On Wed, Mar 05, 2014 at 02:27:08PM +0000, 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)

(Adding fglrx-driver at packages.debian.org back to Cc since the topic of
discussion is its package relationships - I'll clone a bug to it
later, but having one place to discuss seems best for now)

> (I wanted to suggest != relation here as it is what apt does for
> the implicit breaks for Multi-Arch, but noticed that isn't a
> blessed relation so nothing beside apt is supporting it…
> "interesting")

Right - I tried "!=" first, got syntax errors from dpkg, thought "hmm,
that's strange, I though that was what apt did for the implicit
Breaks?", and tried the other possibilities instead.

> Relational speaking, isn't libgl1-foo-glx breaking the foo-driver 
> and not the other way around?

Maybe. That's what the "+smcv.breaks" variant of my proposed patch
does, but I'm not sure how conceptually sound it is. fglrx-driver
contains the X-server-side driver, whereas libgl1-foo-glx contains the
libGL implementation to be loaded by X clients.

I believe fglrx-driver can operate correctly without libgl1-foo-glx
(you'll get pixels on the screen, but no 3D acceleration). A
Recommends does seem appropriate in that direction, though, since
there's little reason to prefer the proprietary driver unless you're
going to benefit from its 3D acceleration. Conversely, I don't think
libgl1-foo-glx can operate correctly unless fglrx-driver is loaded
into your X server.

Perhaps it's really more like fglrx-driver Recommends: libgl1-foo-glx
(= this), libgl1-foo-glx Depends: foo-driver:any (= this)? I'm not sure.

In practice, I think the high-level thing we want is "if they're both
installed, these packages upgrade in lockstep" - from that point of
view, Breaks (<<), (>>) in fglrx-driver has the same practical effect
as Breaks (<<) in both packages, and the effect of Depends (=) in one
package is also similar.

> Also, if I wanted to install libgl1-foo-glx:i386, wouldn't I
> install foo-driver:i386 ?

No, not necessarily. fglrx-driver contains modules that are loaded
into your single X server, whereas libgl1-fglrx-glx contains a library
that is loaded into multiple, potentially mixed-architecture X
clients. For instance, if you have xserver-xorg:amd64 and you want to
run openarena:amd64 and steam:i386 with the fglrx driver, you'll need
f-d:amd64 (to get pixels on the screen), l-f-g:amd64 (to get fast
OpenGL in openarena), and l-f-g:i386 (to get fast OpenGL in steam).

> Personally, I would prefer reverting to the previous depends, but
> that isn't my business… but: think of all the kittens^Wpartial
> upgrades.

By "reverting to the previous depends" do you mean the "+smcv.dep"
variant of my proposed patch? That's what we've done in SteamOS, at
least for now.

> Thanks for the testcase! If you deal more often with this kind of
> tests you can have a look at our tests in test/integration/. It
> allows 'real' minimal tests. It doesn't have uu support, but I
> guess Michael would actually like to have it.

Yeah, my test-case was somewhat inspired by yours in apt - but I
initially thought this was a bug in unattended-upgrades' "minimal
steps" logic, and it wasn't clear to me how best to generalize
unattended-upgrades' tests, so I needed packages that I could work
with on a live system.

> jftr: foo-driver shouldn't be deconfigured (this isn't done by apt,
> but by dpkg automatically based on dependencies - but foo-driver
> hasn't any).

Ah, I think I see: a Breaks is an inverse Depends, so if A Breaks B,
it will only ever be B that gets deconfigured, the same as if B
Depends A, it will only ever be B that gets deconfigured? Then my
"+smcv.dep" patch adds a Depends, or my "+smcv.breaks" patch adds a
Breaks in the other direction, either of which is enough to get
fglrx-driver deconfigured too.

> Lets start with the good news: I have a patch attached fixing
> this. Even better: It removes lines of code rather than adding some
> new. The "bad" thing is that I am usually quiet scared then it
> comes to changes to the ordering (as the testing happens at
> release+1 time).

Sure, I understand that this is a concern. I'm afraid I don't
understand the insides of apt in sufficient detail to have much to say
about your proposed solution, but delaying configuration does seem
reasonable.

For upgrades from wheezy to jessie to work with wheezy's apt, I think
fglrx-driver will *also* have to take one of the two changes I
suggested in a previous mail, unless you have a better idea? I'll
clone the bug to fglrx-driver when there's consensus on what it should
do, and bump the severity up to serious if I can reproduce this
failure on a pure wheezy->jessie upgrade.

It's a pity piuparts doesn't operate on the contrib and non-free
archive areas, and also doesn't mix multiarch architectures, both of
which would have been necessary to see this fglrx-driver upgrade failure.

I don't suppose there's enough capacity on piuparts.d.o to do a
variant of wheezy2jessie that installs jessie's apt before upgrading,
and compares the results with the wheezy2jessie that used wheezy's
apt? That would seem a reasonable way to get some level of confidence
that you haven't broken upgrades too much by re-ordering, even if it
doesn't go into the weirder corner cases like mixing architectures.

    S