On Tue, Oct 6, 2009 at 9:46 PM, lee <l...@yun.yagibdah.de> wrote: > 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).
Doing that would probably not be possible, given the nature of this particular component. nvidia's drivers have always had a kernel-space component and a user-space component (the user-space component is nvidia-glx, the kernel is nvidia-kernel-source or variations thereof). Not having nvidia's drivers completely opem makes the process more complicated, since other drivers (intel, for example) have begun to put some of their code in the kernel proper, but essentially from the user's perspective it's a unified driver that exists totally in userspace. What complicates the matter further is that the kernel space part of the driver has to match the kernel you run. If you're on stable or testing then you might not have new versions of the kernel just popping up, but if you change the kernel, you have to rebuild the module. In some respect ubuntu automates this process - and perhaps debian does as well; I've not actively used nvidia since switching to intel back in December. But for instance, my virtualbox has a kernel space part and that gets automatically updated as part of the upgrade process any time the kernel changes. (And on karmic, new revs of the kernel are somewhat frequent.) But in general, separation of components is not uncommon. Sometimes documentation is separated from the executable, or a development set is separated from the libraries. That's to save on space, and not everyone who has a particular library needs the development component automatically installed. -- thanks for letting me change the magnetic patterns on your hard disk. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
