I am working on a ebuild for driver on demand, a system for autodetecting hardware, then download and install drivers for it. Since it took more time then I thougth, I created this bug so others can continue on what I have done instead of duplicating effort. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 31469 [details] driverondemand-0_alpha1.ebuild ebuild for driverondemand, exept the standard dependencyes
Created attachment 31470 [details] XML-Validator-Schema-1.06.ebuild dependency for driverondemand needs Tree::DAG_Node (found in) bug 39200 and Test::More (coming soon)
Changed status to wait, since it is not all working yet, and I dont want to bug the gentoo-team before it is ready
Created attachment 31476 [details] driverondemand-0_alpha1.ebuild added the standard dependencyes currently used (exept dbus and sendmail, since dbus is not used and sendmail is not coded yet)
Created attachment 31478 [details] XML-Validator-Schema-1.06.ebuild Seems like Test::More is included in Perl, no need for taht
Created attachment 31479 [details] XML-Validator-Schema-1.06.ebuild actually works (removed a * that had come in before DEPEND, and I did not remove beliving it was a pointer :))
Created attachment 31500 [details] MIME-Base64-Perl-1.00.ebuild Seems like it was MIME-Base64-Perl, no MIME-Base64 dod depended on.
Created attachment 31502 [details] driverondemand-0_alpha1.ebuild I have created a ebuild that works for me. (I can run the program) However, to do it, I modifyed code I dont have copyrigth on, so that issue must be fixed. I also did some changes to the code. Now, it is almoust 2:00 in my timesone, so I wont look at that until later
Created attachment 31579 [details] driverondemand-0_alpha1.ebuild Corrected some spellingmistakes, and added the requirement for 2.6 to the description (found no way to set it as a dependency) The copyright issue is resolved, thanks to Andrew Luecke. (I have put comments on it in the ebuild, so you Gentoo-folks can see that the copyrigth-issue is ok. I am fully aware off that it will be removed before entering the portagetree)
I belive the ebuild now is ready for inclusion, as all the issues are solved
putting this bug to the livecd team, as they are the ones most active in the area of hardware autodetection
The Gentoo LiveCD doesn't have perl on it, as it is too heavy of a dependency to leave on the system. Would this not be better suited in another group, as we can't use it.
hey... I'm the coder of driver on demand.. Actually, perl is being dropped in Alpha 2 (going thru a massive porting effort). Was initially to D, but I found out you guys cant carry that compiler due to the well designed license, so alpha 2 will use C++.. It will however probably have a libXML, libHAL dependency, and Dbus dependency (libhal requires DBUS to operate anyway). So is it still too heavy to include?
Chris, with the above changes, will it still be heavy?
Right now we don't use Dbus, at all. We would really have to evaluate whether or not it would be feasable for us to use. I can guarantee you that it would not make it into 2004.2, as we have already frozen features (releng features, not portage features/packages) for that release. I also doubt that it would make it into 2004.3, which I've already started work on... ;] Currently, we are working to even have proper udev support on the LiveCD, so that we can switch to an entirely 2.6 kernel on the LiveCD. This might be something we would look into, but like I said, unless it just magically works perfectly as soon as we try it, and it is easy to implement, it probably won't see any kind of inclusion for a long time. One of my main focuses with the LiveCD's is stability and quality. With that in mind, I tend to avoid introducing things without giving it extensive testing. What that would mean is that even if we were to decide to use driver on demand, it would probably spend at least 2 release cycles in "testing", which means it wouldn't show up on a release CD at all until after that.
OK, I'll leave this assigned to you guys then, since it's potentially most useful in that environment. Greg KH, can you weigh in with an opinion on this please?
My opinion? Sure you want it? :) Anyway, I think this goes against the whole general philosphy that the linux kernel has. Namely that all drivers will be included in the main kernel tree. This is done for many, good, valid, technical reasons, and has allowed Linux to now support more devices "out of the box" than any other operating system today. It has also allowed us to have a lean and mean os without any messed up apis that out of the tree drivers require over the long run. Anyway, I don't see any need for this except for a few minor drivers that are not part of the main kernel tree. And for them, time spent on getting those drivers into the main kernel tree would be a much better thing to do. But hey, that's just my opinion :) Anyway, I would not recommend adding this to any released product, livecd included. If the livecd group finds any missing drivers from the current kernel package that they need, please let me, and the rest of the kernel@g.o team know and we will fix that.
I had mentioned that we can't use it. I very seriously doubt that we ever would. I tend to agree with Greg on this one. If we find a driver that needs to be added, we'll have the kernel team add it. I would have a problem with using something like this on the LiveCD, as it would give our users a very wrong impression. After all, what if your driver was loaded via this interface, but then wasn't available in the "gentoo" kernel sources? Would that not make it seem like we don't know what we are doing? Inconsistency is a showstopper for is. As it is now, we would not even consider this. Perhaps when the rewrite is completed, a new bug should be filed at that time for consideration, but for now, I'm marking this one as WONTFIX.
What about adding it to portage so it can be used by others? I think I am not the only one that have hardware that I don't know how to make work, and are tired of trying to make it work. Someting like this (scanns the hardware and then finds the needed drivers for you from a online database, not based what drivers you happend to compile in during the kernelcompilation, or by chance you already have installed) could help us. To find drivers etc. is fun for the first computer (you leran a lot), but when you have a lot of different machines to set up, finding what drivers youre hardware need can be a real pain. Espessially when the geious that bougt the computers bought finish buid ones with non-standard parts.
There's nothing stopping you from using it, at all. The kernel guys say that they don't like it and that they would rather get bugs reported for hardware so they can fix it in the kernel. The livecd team (which is just me, by the way) doesn't want it, since I won't be using it any time soon. We don't add packages to portage that we don't intend on maintaining. I would suggest taking this ebuild over to BMG. They're always open for new things.
OK, thanks for the advise. I just followed it. :) http://bugs.breakmygentoo.net/show_bug.cgi?id=416
=]
