Hi Bruce, thanks for the feedback... On Mon, Feb 21, 2005 at 09:39:15PM +0000, Bruce Stephens wrote: > The generated package seems to contain an empty directory > /etc/modprobe-before-usbhid.d/wacom
oops, this is vestigal from a really ugly hack in the unreleased 0.6.6-5 packages. We do this with the aid of hotplug and some new code kernel side now for kernel2.6 -- and 'add below' still works as a workaround for kernel 2.4. > I can't seem to find documentation for what it ought to be (presumably > a file in /etc/modprobe.d), but this doesn't seem to cause wacom to be > loaded before usbhid. Not by itself. It was just a flag for a worker script that needed to be shared with other module packages. It started as a proof of concept that you really can do everything with the new generation module tools that was supported by the old, and turned into a good lesson about why not to even try. [ in short modprobe.d is simply not the right place to define module inter-relationships and there are other options on the horizon ] anyway, it is (otherwise harmless) cruft now and /etc/modprobe-before- can be safely removed. > When I added "rmmod wacom; rmmod usbhid" to > /etc/init.d/gdm, I got X back again (before that X failed to start, > since the wacom mouse is my primary pointer). Please try removing those lines again once you have a clean install of the >= -7 packages (including the generated module package), and let me know if it still doesn't work. If by some chance it doesn't, then: a) Change your XF*^Config-4 to use /dev/input/wacom instead of whatever /dev/input/event* you have there now. This will free you from trouble with the order modules and devices are probed. b) If a) doesn't work: add: echo 1 > /sys/module/wacom/parameters/rebind in place of the rmmod ... above, and give me another ping whether b) works or not :-) hotplug should have already taken care of this for you by the time X is looking for a core pointer, if not, we should look at why. > Some minor things. Most kernel module source packages (all those I've > tried other than wacom-kernel-source) seem to install a suitable > gzipped/bzipped tarball into /usr/src; that makes it convenient to > switch building on or off. I'm not sure exactly what you are doing here, but I do consider having to shuffle tarballs around to be a bit on the ugly side of good package management. (aka: if I wanted to juggle tarballs, why do I mess with .debs) I fairly blatantly nicked some ideas from some packages of rmh which I liked and which I've run with to try and may things as convenient as possible, but I'm not sure what you need here... make-kpkg has --added-modules to do what you suggest, and/or you can manually move other things (like the source dir) just as easily as a tarball. You already have a 'tarball' of the source if you still have the -source.deb installed, I find it hard to justify forcing most users to keep three copies of the source (two packed, one unpacked) on their system to use this package. But I'm also not clear on precisely how you expect kernel module builds to work either. There are a lot of 'common' ways to do this, and I am keen to pinch the best ideas of all of them and normalise away some of the less inspired ones -- so if there is something lacking here, I'd certainly like to know more about it. > I've never needed to do "make-kpkg > modules-config" except for this package (just "make-kpkg > modules-image" worked). yes, and you shouldn't need to for this one either. Most kernel modules have little business running a configure script and this one is no different. Except for the fact that the upstream build system ties building the kernel module very tightly with building the tools to use it. Jens posted about fixing this recently, so relief is in sight for this one. > All other module source packages seem to > cause their packages to be built in /usr/src (well, probably in .. > relative to where make-kpkg is run). This is genuine unspecified behaviour in Debian. I had packages doing both on my system at the time I first uploaded these, and I crunched all the factors through my head and decided that using '..' (relative to where debian/rules was run) was preferable for more reasons than using $(KSRC)/.. [ And you can always set MODDIR='$(KSRC)/..' if you want the other behaviour. ] I couldn't honestly tell you all those reasons any more, but if someone is interested in adjudicating the arguments and writing up a proposal for -policy, I'll be glad to try to remember them. Consistency here would be nice, for many more reasons than already mentioned. > I'm not sure that any of these are bugs, so to summarise ;-) modprobe-before is not (anymore) -- I'll get you a new release for that one, with the brown paper wrapping this time I think... If X still doesn't start, that is a bug. I'll keep this open until you ack that. The same configuration is 'working for me' as I (in fact, enabling me to) type this. The rest I think are genuine wishes. A couple I think I can help with to some degree, ping me off the bts -- the rest are really in the domain of -policy. I don't want to start moving things about just to follow the tide of fashion, but if a motivated monkey herder comes along with an eye to drafting a policy specification that we could all adhere to, then I'd be keen to comment on that from an implementor point of view, and to follow it if sane. > as such---but they make this package different from similar > ones, which seems unhelpful. Indeed. Unhelpful differences bug me too. We should be able to scratch most of these, if scratch is the word I want, without too much trouble. cheers, Ron -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
