David and I have had some useful discussions about this on IRC over the last
couple of days; let's recap here for those who haven't been around on
#debian-x.
On Wed, Aug 16, 2006 at 08:59:41PM +0000, David Nusinow wrote:
> Some pieces of this are already in place. The various Xorg applications
> are all in unstable, as are the protocol headers.
With the exception of x11proto-fixes, which breaks API compatibility with
both the server and libxfixes due to a protocol change, so all three of
these need to be uploaded at the same time.
> The libraries are currently in experimental. Most are minor updates, but
> two feature changes that are of interest to the release team. One is
> libxfixes, which had an soversion change from 3.0.0 to 3.1.0. I have added
> an shlibs file to the package as a result. The other is xft. This has a
> slightly altered public API, and several symbols are no longer exported. I
> have also added a shlibs file to this package because of this. Both of
> these updated packages will be in incoming within a few hours.
Clarification: the libxfixes change is a shlibs change, not an soname
change. ("soversion" normally refers to the numeric component of an soname;
apparently xorg upstream uses the term differently.)
And the libxft symbol changes are to symbols which have never been exposed
in public headers, so this is not a change to the public ABI and should
therefore not be a shlibs change. David has already indicated he plans to
revert this shlibs change in the package.
> This release of the X server features an internal ABI bump. As such,
> we've had to rebuild all of the X video drivers. This task is now complete
> and all of them are either in experimental or incoming. The current X
> server in experimental is FTBFS due to an incorrectly specified mesa
> build-dep, but this is fixed in svn and will be uploaded in a few hours as
> well.
The major question here has been how to handle binary non-free drivers that
haven't been updated yet for the 7.1 ABI change. Specifically, the nvidia
driver, which is presently packaged in non-free, hasn't been updated yet for
7.1; it's possible that this won't happen in time for the etch release, or
even that it won't happen at all if they jump straight to a 7.2 ABI. David
seemed unconcerned by the possibility of releasing etch without an nvidia
driver. That's a fair answer, I just wanted to make sure we weren't going
to leave people taken by surprise by such a change. We've also discussed
steps that can be taken to help nvidia users continue to use the 7.0 driver
with the 7.1 server if that becomes necessary, and David has been working up
a patch for an IgnoreABI xorg.conf option to supplement the -ignoreABI
commandline option, which leaves me comfortable with the worst-case scenario
here (i.e., we can ship nvidia 7.0 drivers and users of those drivers will
have to add a couple of options to their xorg.conf by hand).
> Please note that mesa will also need to be uploaded to unstable. The
> current version in experimental is a CVS snapshot, however we require a
> development version of mesa to build and run the current X server. Mesa
> upstream is supposed to do a release soonish, and we'll look to get it in
> to Debian ASAP so that we don't have to ship etch with a CVS pull.
> Currently though, it's looking pretty stable for a large number of users,
> so I think this won't be a problem.
Mesa snapshot vs. released version in etch doesn't concern me greatly; the
larger question is what's acceptable to the package's maintainer, I think.
I have concerns about mesa packaging, which seems complex and ever-changing,
but those are unrelated to xorg 7.1 in etch.
So my conclusions are:
- 7.1 libs, including libxft but excluding libxfixes and libx11 (which has a
separate segfault problem not mentioned above), can be uploaded to unstable
whenever the maintainers see fit, with the understanding that none of
these libs include ABI changes (backwards-incompatible or otherwise).
- Uploading a mesa suitable for xorg 7.1 is a matter to be settled between
the XSF and the mesa maintainer.
- x11proto-fixes, libxfixes, and the server and drivers all need to be
uploaded together; you're free to do this as soon as the IgnoreABI patch
is tested and mesa is sorted out. libxfixes has about 500
reverse-dependencies in testing that will be affected by the shlibs bump,
but AFAICS libxfixes is tied to the server only by build-deps, which means
the server won't delay getting the libxfixes update into unstable. (if
anyone has reason to believe otherwise, please speak up!)
- libx11 will be kept at the 7.0 version for etch, because no one has time
to sort out the segfault problems, and the new version of this lib isn't
on the critical path for any of the other updates.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature