[gentoo-dev] xorg-server 1.0.99/1.1 ABI break

[gentoo-dev] xorg-server 1.0.99/1.1 ABI break

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 823 bytes --]

Hi all,

Just wanted to make you aware that xorg-server 1.1 (and all release
candidates, including 1.0.99 and up) breaks the server-driver ABI from 1.0.

This means drivers are not compatible following an upgrade of
xorg-server, and both sides will require an update to work again properly.

This also means that all binary drivers (nvidia, ati, etc) will be
broken with xorg-server 1.1 and RC's until their upstream vendor
provides a compatible update.

Everything with the new ABI is currently masked, but when X.Org 7.1 is
released, will come out of package.mask.

We are working to ensure the dependencies work as smoothly as possible,
but I expect there will be some issues since it's difficult to require
updates to all these optional drivers following an update to the server.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-dev] xorg-server 1.0.99/1.1 ABI break

[Simon Stelling]

Donnie Berkholz wrote:
> We are working to ensure the dependencies work as smoothly as possible,
> but I expect there will be some issues since it's difficult to require
> updates to all these optional drivers following an update to the server.

wouldn't !< atoms solve that problem?

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] xorg-server 1.0.99/1.1 ABI break

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 641 bytes --]

Simon Stelling wrote:
> Donnie Berkholz wrote:
>> We are working to ensure the dependencies work as smoothly as possible,
>> but I expect there will be some issues since it's difficult to require
>> updates to all these optional drivers following an update to the server.
> 
> wouldn't !< atoms solve that problem?

The drivers cannot be upgraded until a newer server is installed. So
technically, this would allow things to work by forcing people to
unmerge all their drivers before upgrading, then remerge the new
versions. That's not a very desirable solution either, but do you think
it's the best one?

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-dev] xorg-server 1.0.99/1.1 ABI break

[Alec Warner]

Donnie Berkholz wrote:
> Simon Stelling wrote:
> 
>>Donnie Berkholz wrote:
>>
>>>We are working to ensure the dependencies work as smoothly as possible,
>>>but I expect there will be some issues since it's difficult to require
>>>updates to all these optional drivers following an update to the server.
>>
>>wouldn't !< atoms solve that problem?
> 
> 
> The drivers cannot be upgraded until a newer server is installed. So
> technically, this would allow things to work by forcing people to
> unmerge all their drivers before upgrading, then remerge the new
> versions. That's not a very desirable solution either, but do you think
> it's the best one?
> 
> Thanks,
> Donnie
> 

Well the semantics of the blocker is that the new driver won't work with 
the old server; is that true?  Or just the old drivers won't work with 
the new server?

I dislike using blocks to push users to fix issues; instead using guides 
and such.  But this is one of those things; how do you inform a bunch of 
  people, many who don't understand what an ABI is, to upgrade their 
system in the proper order without them getting all pissed off at you 
for lack of guidance ;)

My experience is limited only to #gentoo and the forums, but upgrade 
snags of that sort generally hit both of those areas rather quickly, 
making them easier to find.  Of course this screams changelogs/news GLEP 
  material as well ;)

-Alec

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] xorg-server 1.0.99/1.1 ABI break

[Donnie Berkholz]

Alec Warner wrote:
> Well the semantics of the blocker is that the new driver won't work with 
> the old server; is that true?  Or just the old drivers won't work with 
> the new server?

New server requires new drivers. Old server requires old drivers. There 
is no valid combination of new and old.

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] xorg-server 1.0.99/1.1 ABI break

[Olivier Crête]

[-- Attachment #1: Type: text/plain, Size: 540 bytes --]

On Mon, 2006-17-04 at 13:05 -0700, Donnie Berkholz wrote:
> Alec Warner wrote:
> > Well the semantics of the blocker is that the new driver won't work with 
> > the old server; is that true?  Or just the old drivers won't work with 
> > the new server?
> 
> New server requires new drivers. Old server requires old drivers. There 
> is no valid combination of new and old.

Then you should probably has new drivers block old servers and new
servers block old drivers...

-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-dev] xorg-server 1.0.99/1.1 ABI break

[Thomas de Grenier de Latour]

On Mon, 17 Apr 2006 09:19:48 -0700,
Donnie Berkholz <spyderous@gentoo.org> wrote:

> Simon Stelling wrote:
> > Donnie Berkholz wrote:
> >> We are working to ensure the dependencies work as smoothly as
> >> possible, but I expect there will be some issues since it's
> >> difficult to require updates to all these optional drivers
> >> following an update to the server.
> > 
> > wouldn't !< atoms solve that problem?
> 
> The drivers cannot be upgraded until a newer server is installed. So
> technically, this would allow things to work by forcing people to
> unmerge all their drivers before upgrading, then remerge the new
> versions. That's not a very desirable solution either, but do you
> think it's the best one?
> 

What about a big PDEPEND in xorg-server-1.1 ebuild, with a bunch of
"video_cards_foobar? ( >=x11-drivers/xf86-video-foobar-NewVersion )"?
That should be enough to force a smooth update of the video drivers
after the server. And, the RDEPEND on video drivers could be removed
from the xorg-x11 meta-ebuild, to avoid redundancy.

Sure, it doesn't help users who have manually emerged some drivers
without listing them all in $VIDEO_CARDS: they will still be able to
update their server and keep some old broken drivers behind. But
hopefully, they won't be so numerous (much less numerous than those who
would be annoyed by some "!<..." block imho).

--
TGL.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] xorg-server 1.0.99/1.1 ABI break

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 347 bytes --]

On Monday 17 April 2006 22:26, Olivier Crête wrote:
> Then you should probably has new drivers block old servers and new
> servers block old drivers...
Better have new drivers depend on new server rather...

-- 
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-dev] xorg-server 1.0.99/1.1 ABI break

[Donnie Berkholz]

Olivier Crête wrote:
> On Mon, 2006-17-04 at 13:05 -0700, Donnie Berkholz wrote:
>> Alec Warner wrote:
>>> Well the semantics of the blocker is that the new driver won't work with 
>>> the old server; is that true?  Or just the old drivers won't work with 
>>> the new server?
>> New server requires new drivers. Old server requires old drivers. There 
>> is no valid combination of new and old.
> 
> Then you should probably has new drivers block old servers and new
> servers block old drivers...

OK, let's think about the results of this.

New drivers block old servers:
	Rather, why wouldn't new drivers depend on a new server? This makes 
sense and is already what we're doing.

New servers block old drivers:
	This will require people to uninstall all their drivers to upgrade 
their server. It will not automatically reinstall them in the 'emerge -u 
xorg-server' case, but it _should_ reinstall them in the 'emerge -u 
world' case _if_ they're using the xorg-x11 metabuild.

I'm not sure whether portage does a --deep by default now, but I think 
that's what is necessary for correct behavior in the 'emerge -u world' case.

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] xorg-server 1.0.99/1.1 ABI break

[Donnie Berkholz]

Thomas de Grenier de Latour wrote:
> What about a big PDEPEND in xorg-server-1.1 ebuild, with a bunch of
> "video_cards_foobar? ( >=x11-drivers/xf86-video-foobar-NewVersion )"?
> That should be enough to force a smooth update of the video drivers
> after the server. And, the RDEPEND on video drivers could be removed
> from the xorg-x11 meta-ebuild, to avoid redundancy.

That's a very reasonable idea in the current situation. The problem is 
that the xorg-server ebuild will begin building more and more X servers 
based on various combinations of USE flags. For example, kdrive will be 
part of xorg-server 1.1. Xgl will likely be part of xorg-server 1.2. 
Already we've got Xdmx, Xnest, Xorg and Xvfb.

Clearly one may desire to install only a certain set of these servers. 
Right now, my working copy has it set up so that USE=minimal in 
combination with USE=(dmx|kdrive|xgl|other group of servers) causes the 
Xorg server to not get built. But expressing that in RDEPEND gets quite 
complex.

Perhaps the "minimal" flag is the wrong way to go, and instead I should 
add a "xorg" flag that defaults on to build the Xorg server. That 
approach would allow for a reasonably simple expression of the driver 
PDEPENDs inside like this: "xorg? ( driver list )".

> Sure, it doesn't help users who have manually emerged some drivers
> without listing them all in $VIDEO_CARDS: they will still be able to
> update their server and keep some old broken drivers behind. But
> hopefully, they won't be so numerous (much less numerous than those who
> would be annoyed by some "!<..." block imho).

A valid problem with this approach. Is requiring everyone to unmerge 
drivers a worse solution than breaking some people who emerged drivers 
directly?

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] xorg-server 1.0.99/1.1 ABI break

[Alec Warner]

Donnie Berkholz wrote:
> Olivier Crête wrote:
> 
>> On Mon, 2006-17-04 at 13:05 -0700, Donnie Berkholz wrote:
>>
>>> Alec Warner wrote:
>>>
>>>> Well the semantics of the blocker is that the new driver won't work 
>>>> with the old server; is that true?  Or just the old drivers won't 
>>>> work with the new server?
>>>
>>> New server requires new drivers. Old server requires old drivers. 
>>> There is no valid combination of new and old.
>>
>>
>> Then you should probably has new drivers block old servers and new
>> servers block old drivers...
> 
> 
> OK, let's think about the results of this.
> 
> New drivers block old servers:
>     Rather, why wouldn't new drivers depend on a new server? This makes 
> sense and is already what we're doing.
> 
> New servers block old drivers:
>     This will require people to uninstall all their drivers to upgrade 
> their server. It will not automatically reinstall them in the 'emerge -u 
> xorg-server' case, but it _should_ reinstall them in the 'emerge -u 
> world' case _if_ they're using the xorg-x11 metabuild.
> 

I'll take TGL's suggestion, New server PDEPENDS on new drivers.

New drivers need new server, old drivers won't work with new server, 
doesn't touch the old driver ebuilds at all; I don't particularly see a 
down side ;)

> I'm not sure whether portage does a --deep by default now, but I think 
> that's what is necessary for correct behavior in the 'emerge -u world' 
> case.
It doesn't.
> 
> Thanks,
> Donnie

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] xorg-server 1.0.99/1.1 ABI break

[Alec Warner]

> 
> 
> A valid problem with this approach. Is requiring everyone to unmerge 
> drivers a worse solution than breaking some people who emerged drivers 
> directly?
> 

I very much dislike making people unmerge things.  It's not intuitive 
for anyone, having to remove the old program to upgrade a dependency of 
the new one?

> Thanks,
> Donnie

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] xorg-server 1.0.99/1.1 ABI break

[Thomas de Grenier de Latour]

On Mon, 17 Apr 2006 13:43:32 -0700,
Donnie Berkholz <spyderous@gentoo.org> wrote:

> Is requiring everyone to unmerge drivers a worse solution than
> breaking some people who emerged drivers directly?

Depends how many people are on each side i guess. But here, i would
expect really very few people to be on the "broken drivers" side.
To fall there, they should have:

 - set $VIDEO_CARDS to some valid value, but wich doesn't include the
said drivers.  I assume most people tend to either set it to the right
values for their hardware, or, if they don't care / don't understand
what it is, leave it unset (which is fine too since it defaults to
installing all drivers).

 - asked explicitly an update of the X server, but not a world update. 
I can speak only for myself, but that's usually something i do with a
good reason, when i'm aware of some change i want to immediatly apply,
so it's particularly unlikely that it ends with bad surprise. (Or maybe
they could have done a world update but installed their driver with
--oneshot, but again, why?)

 - ignored the shiny VIDEO_CARDS="-yourdriver" in -p output before the
actual update.  This one is just like if an ebuild makes optionnal a
feature which used to be default; it can happen that one don't see the
change in -p output and thus lose the feature, but again, it's
unlikely, and he can't really complain...

So imho, that's a lot of unlikely conditions one should join to end
with broken drivers, and i don't think you should care too much about
it.

The ati --> {mach64,radeon,r128} change may make some of the above more
likely to happen though: for instance, i have VIDEO_CARDS="ati dummy"
on my laptop, and with 'ati' deprecation, only 'dummy' would get
updated. But:
 - at the opposite of the xorg-x11 meta ebuild, a pkg_setup check
xorg-server ("if hasq ati $VIDEO_CARDS; then eerror ...") makes sense,
since it would die at the right time, before the drivers updates.
 - it's not really specific to this PDEPEND thing and driver ABI change
anyway; one may also lose Mesa support for his ATI card if he has
other valid drivers listed. Again, "emerge -p" is our friend, and
there is not much to do for people who don't use it.

--
TGL.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] xorg-server 1.0.99/1.1 ABI break

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 805 bytes --]

Thomas de Grenier de Latour wrote:
> So imho, that's a lot of unlikely conditions one should join to end
> with broken drivers, and i don't think you should care too much about
> it.

Thanks for your input.

> The ati --> {mach64,radeon,r128} change may make some of the above more
> likely to happen though: for instance, i have VIDEO_CARDS="ati dummy"
> on my laptop, and with 'ati' deprecation, only 'dummy' would get
> updated. But:
>  - at the opposite of the xorg-x11 meta ebuild, a pkg_setup check
> xorg-server ("if hasq ati $VIDEO_CARDS; then eerror ...") makes sense,
> since it would die at the right time, before the drivers updates.

FYI, the video cards stuff makes use of USE_EXPAND. This means that we
don't use has/hasq, we do 'use video_cards_ati'.

Thanks,
Donine


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 251 bytes --]

Re: [gentoo-dev] xorg-server 1.0.99/1.1 ABI break

[Thomas de Grenier de Latour]

On Mon, 17 Apr 2006 17:48:07 -0700,
Donnie Berkholz <spyderous@gentoo.org> wrote:

> >  - at the opposite of the xorg-x11 meta ebuild, a pkg_setup check
> > xorg-server ("if hasq ati $VIDEO_CARDS; then eerror ...") makes
> > sense, since it would die at the right time, before the drivers
> > updates.
> 
> FYI, the video cards stuff makes use of USE_EXPAND. This means that we
> don't use has/hasq, we do 'use video_cards_ati'.

Yup, actually i knew but here we don't want "video_cards_ati" in IUSE
(would be confusing in "emerge -p" since it's not a valid value), hence
the 'hasq' to avoid the QA notice :) 

But maybe you're right, "use ... 2>/dev/null" would be simpler.

--
TGL.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] xorg-server 1.0.99/1.1 ABI break

[Sebastian Bergmann]

[-- Attachment #1: Type: text/plain, Size: 517 bytes --]

Donnie Berkholz schrieb:
> This also means that all binary drivers (nvidia, ati, etc) will be
> broken with xorg-server 1.1 and RC's until their upstream vendor
> provides a compatible update.

 Do you know whether these upstream vendors (I am interested in nVidia
 mostly) plan to release new drivers in time for the xorg-server 1.1
 final release?

-- 
Sebastian Bergmann                      http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [gentoo-dev] xorg-server 1.0.99/1.1 ABI break

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 540 bytes --]

Sebastian Bergmann wrote:
> Donnie Berkholz schrieb:
>> This also means that all binary drivers (nvidia, ati, etc) will be
>> broken with xorg-server 1.1 and RC's until their upstream vendor
>> provides a compatible update.
> 
>  Do you know whether these upstream vendors (I am interested in nVidia
>  mostly) plan to release new drivers in time for the xorg-server 1.1
>  final release?

They will release when they're ready. I'm not privy to their release
dates, but I know they're aware of the changes.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]