On Tue, 24 Aug 2010 20:07:03 -0700 Jan Muszynski wrote: > On Mon, Aug 23, 2010 at 8:15 PM, Michael Gilbert > <michael.s.gilb...@gmail.com> wrote: > > On Fri, 20 Aug 2010 20:50:01 -0700 Jan Muszynski wrote: > > > >> What you show is virtualbox-ose. Compare to PUEL. And no, you can't > >> say it's a bug in the PUEL implementation. Note that when you run > >> /etc/init.d/vboxdrv setup it: > >> 1) Does use dkms if it's available > >> 2) Explicitly processes the drivers in order > >> Anyway: > >> > >> ls /var/lib/dkms > >> dkms_dbversion nvidia vboxdrv vboxnetadp vboxnetflt > >> > >> apt-show-versions -a virtualbox-3.2 > >> virtualbox-3.2 3.2.8-64453~Debian~lenny install ok installed > >> virtualbox-3.2 3.2.8-64453~Debian~lenny lenny download.virtualbox.org > >> No testing version > >> No unstable version > >> virtualbox-3.2/lenny uptodate 3.2.8-64453~Debian~lenny > >> > >> > >> The issue that I originally filed this on obviously isn't critical. > >> For my own purposes I can easily correct this. The general issue > >> remains though. What order should the various dkms modules get > >> compiled in? I think the only logical order is sorted alpha, since if > >> there are modules with inter-related dependencies that would be what > >> they logically would use. For other, standalone, modules the order > >> doesn't matter so it's no harm no foul. > >> > >> Bottom line it's a simple change and I don't see how it could possibly > >> hurt anything, so I'm unable to understand the resistance/reluctance > >> to implement it. > > > > yes, your suggested change is simple; however, it doesn't generalize > > since module names won't necessarily be alphabetical. > > > > however, the core problem here is that the PUEL (Personal Use Evaluation > > License) version of virtualbox is not provided by debian, and thus we > > can't directly support it. for the bugs you find in that, you need to > > submit reports to the upstream bug system directly. > > 1) I don't think you can classify this as a "bug" in PUEL :)
it's a bug in PUEL since it expects dkms to behave in a way that isn't necessarily guaranteed. this problem has already been solved in the debian-supported virtualbox-ose package. you should suggest to PUEL upstream to adopt the existing fix. > 2) I'm not asking you to "directly support it". The support is a side effect. we can't possibly anticipate/handle all cases of bad behavior in dkms using tools (especially for proprietary variants). the bad behavior itself should be fixed directly in the offending application. > All that aside answer me this question, because it's not obvious to > me. What order does the find command return the listing in? It's > consistent so there's some order to it, but I can't determine what it > is. > > I get (for the above directory): > > dkms$ find . -maxdepth 1 -mindepth 1 -type d -a -not -name original_module > ./vboxnetadp > ./vboxnetflt > ./nvidia > ./vboxdrv > > It's not time based: > drwxr-xr-x 3 root root 4096 Aug 24 11:17 nvidia > drwxr-xr-x 3 root root 4096 Aug 24 11:20 vboxdrv > drwxr-xr-x 3 root root 4096 Aug 24 11:20 vboxnetadp > drwxr-xr-x 3 root root 4096 Aug 24 11:20 vboxnetflt find is highly optimized, and its output order is highly dependent on the layout of low-level file system structures. there is no guarantee of any particular order. mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
