[Pkg-dkms-maint] Bug#586725: Bug#586725: closed by Michael Gilbert <michael.s.gilbert at gmail.com> (re: dkms attempts to install modules in wrong order)

[Michael Gilbert]

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.gilbert at 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