[ubuntu-x] Proprietary driver ABI handling

[Alberto Milone]

On 1 February 2011 00:52, Christopher James Halse Rogers
<raof at ubuntu.com> wrote:
> On Mon, 2011-01-31 at 23:08 +0100, Alberto Milone wrote:
>> On 30/01/11 23:40, Christopher James Halse Rogers wrote:
>> > Hey all
>> >
>>
>> Hi Chris
>>
>> > As a part of the drive to Xserver 1.10, I've noticed that the fglrx and
>> > nvidia proprietary drivers don't have the appropriate Depends: to
>> > prevent the X server being updated from underneath them. (nvidia bug: LP
>> > #616214, no existing fglrx bug)
>> >
>> > A simple fix would be to add ${xviddriver:Depends} to their dependency
>> > fields, which will add a dependency on the current Xserver video ABI
>> > metapackage.  This is sub-optimal in two ways:
>> > 1) We need to do a mock “rebuild” against each new Xserver ABI
>> > 2) It makes checking Xserver bugs against older ABIs unnecessarily
>> > difficult.
>> >
>>
>> We already do the following:
>> Provides: ${xviddriver:Provides}
>>
>> and rebuild the packages when the ABI changes.
>>
>> I've never thought of using ${xviddriver:Depends} and I was wondering
>> what driver uses that (maybe some open driver?)
>>
>
> ${xviddriver:Depends} is the new(ish, as of ~Maverick?) Debian XSF way
> of keeping the server and drivers in sync.  Rather than have the
> xserver-xorg-core package declare a Breaks on all the ABIs it doesn't
> support, drivers are/will be expected to declare a Depends on the ABI
> they require.  All the open video drivers are (should be?) doing this
> now.
>
> It's expected that drivers will eventually stop Provide-ing
> xserver-xorg-video-$ABI, and instead just Provide: xorg-driver-video.
> That will be handled by the xsfbs helpers, though.
>
>> > Since the proprietary drivers support multiple server ABIs, I suggest
>> > that we keep a list of these in the packaging and add a dependency
>> > satisfied by any of the appropriate xserver-xorg-video ABIs.
>> >
>> > This has the advantage that the default “forgot to update” failure mode
>> > is that an upgrade fails with unresolved dependencies rather than a
>> > broken X, and less work at Xserver upgrade time.
>> >
>>
>> Another problem is that currently, when you try to install the driver,
>> you may end up removing X, which can be a problem ;)
>
> Oooh, yeah.  A Depends: on ${xviddriver:Depends} would solve that,
> too :).
>

Ok then, I'll work on it.

Thanks for bringing this up.

-- 
Alberto Milone
Sustaining Engineer (system)
Premium Engagements Team
Canonical OEM Services