Am Dienstag, den 14.09.2004, 09:50 +0300 schrieb Ville Skyttä: > On Mon, 2004-09-13 at 17:42, Thorsten Leemhuis wrote: > > > > 1) IMO shouldn't use "kernel" for stuff that is not included in kernel > > > distributed by the kernel vendor. > > > > I don't think it's a problem. I think installing the module exactly at > > the same place where it normally would have been installed when you > > compile it also has a lot of benefits. > > Could you elaborate on "lot of benefits", it is not at all clear to me. Mainly Documentation and Howtos of the external drivers. They all will tell you that you find the module in the place, where it is normally installed. I don't see why we should differ from those. And if you install an RPM and later compile a newer driver version locally that is installed at the original place its always the version from the RPM witch will be used -- thats a bit confusing IMO. > Axel already commented why intruding this "vendor space" can cause > problems. I don't see the point here. We need to rebuild the RPM for each kernel anew so we can look after that. Maybe it's something that (also) should be fixed upstream first, then everyone is happy ;-) > > > 2) My #1 pick as of now, maybe, depending on 3) below. > > > > But do we really need to mirror the stucture? Is there any benefit in > > doing so? Why not a simple per-package dir? > > Why not be consistent with what the kernel does? What benefits does a > per-package dir approach have? No strong arguments here. I just find a per-package dir a bit cleaner to read and see no benefits from the structure the kernel has. ;-) ls /lib/modules/uname/(extras|updates)/ simply would show which drivers are installed. No digging trough sub-directorys. > If you are thinking about directory > ownership in module packages, everything below _and including_ the > "updates" or "extra" dirs should be owned by the module package(s) > anyway because the kernel package does not create nor own them. Of course. CU thl
