Re: segmentation fault with NVIDIA 32bit part
On Tue, Oct 06, 2009 at 08:13:57PM -0700, David Fox wrote:
> On Tue, Oct 6, 2009 at 6:59 PM, lee <lee@yun.yagibdah.de> wrote:
> >
> > And nvidia-kernel-common:
> >
> >
> > "This package contains files shared between NVIDIA module packages."
>
> Common refers essentially to support files., You should install the
> package, but it's not dependent on the driver or the version of the
> kernel.
Then why doesn't the description say so?
> > nvidia-kernel-source:
> >
> >
> > "This package builds the NVIDIA Xorg binary kernel module needed by
> > nvidia-glx."
>
> For whatever kernel you have. It's tied to the specific release of the
> driver version, whatever that may be from testing/unstable. Since it
> is source, after you do a module-assistant auto-install, it'll compile
> that driver for the kernel you have. Since you have a non-standard
> kernel, there might be problems, but then again there may not be.
Then the description should say so ...
> > I don't know about vdpaul --- is that included in the nvidia
> > installer?
>
> vdpau is something that's special to some higher-end nvidia cards. You
> may not need that, depending on what card you have.
>
> The link here [1] itemizes supported cards.
Link where? :) I have a 9800GT.
> > Why are the package descriptions so poor, and why can't there just be
> > one package you install?
>
> It would be nice, but essentially you need three components,
> nvidia-glx, nvidia-common and nvidia-kernel-source.
Then there would need to be only two packages: vdpau for those who
need it, and the rest (which could suggest vdpau which could tell you
which cards can use it).
> > Since my card isn't even supported in testing, I'd have to get those
> > packages from unstable. I've tried using packages from unstable a
> > couple times, but the results haven't been good.
>
> Using pinning and judicious use of aptitude install <package> -t
> unstable when only necessary should make things easier.
They _should_: That doesn't mean that they do. Aptitude has a nasty
tendency to do things I don't want it to do. Now imagine what would
happen if I tried to install the nvidia packages from unstable, given
that in testing, they already break another package upon which 95
other packages depend. I might end up having to upgrade to unstable to
solve all the dependency problems.
Unfortunately, there's no roll-back option in aptitude ... or is
there? If there was, there won't be any need to decide between stable,
testing, unstable and experimental and you could try whatever
combination might work. Just tell aptitude "save this current stage",
then try to find something that works, and if it doesn't just tell
aptitude "go back to the saved state".
Are they at least working on that?
Reply to: