[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: nvidia for backported kernel



Holger Levsen <holger@layer-acht.org> writes:

> I'll have to come up for a solution to this (on i386 only) for a
> customer project anyway...

> On Dienstag, 7. Dezember 2010, Russ Allbery wrote:
>> Backporting the NVIDIA packages to stable is difficult because of
>> substantial changes to how ia32-libs works

> thats only relevant for amd64, right?

Yes, and can probably be worked around by adding back in the dependencies
that we had previously removed.

> What would you (all) think about i386 only backports in lenny-backports
> then?  Rather not? Or see it as a first step ;)

It's fine with me; I don't have any strong opinions either way.  I
personally don't have time to help, maintain, or answer user questions,
but Andreas may be willing to help out.  He wrote up a list of things that
would have to be done for a backport a while back in
pkg-nvidia-devel@l.alioth.d.o.  If you're getting started on that,
definitely do mail the mailing list.

>> and because a lot of the cleanup of the packages requires a fairly new
>> version of dpkg.

> Humpf. Is that mentioned sufficiently verbose in changelog? ;)

nvidia-graphics-drivers (195.36.31-5) unstable; urgency=low

[...]

  * libgl*-nvidia-alternatives* needs to Depends: dpkg (>= 1.15) for using
    dpkg-divert --listpackage in the postinst script.

nvidia-graphics-drivers (195.36.31-3) unstable; urgency=low

[...]

  * Remove workaround for dpkg-divert bug #581544, fixed in dpkg 1.15.8.

nvidia-graphics-drivers (195.36.24-3) unstable; urgency=low

[...]

  * nvidia-glx: add Pre-Depends: dpkg (>= 1.15.7.2)
  * nvidia-glx: switch to dpkg-maintscript-helper for removal of obsolete
    config file /etc/default/nvidia-glx
  * nvidia-glx: work around dpkg-divert bug #581544: useless errors on not
    writable destination if source does not exist

I'm not sure if that's all of it.

> That's great, but not an option for those needing lenny with 2.6.32 and
> nvidia now... 2.6.26 is not really an option due to other hardware
> support needed :/

Sure.  More contributions are always welcome!  But given the previous
state of the packages, which were extremely difficult to maintain and very
fragile, trying to get them into a releasable state for squeeze took
precedence over keeping them easy to backport.  The complex diversion and
alternatives system required to keep everything relatively happy is hard
to maintain without a current dpkg.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>


Reply to: