2007/3/9, Aaron Griffin <aaronmgriffin@gmail.com>:
On 3/9/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 3/9/07, James <iphitus@gmail.com> wrote:
4) Modules. I still think that there has to be a better way of dealing with modules. We've put this discussion off once already saying "pacman3". Now pacman3-RC1 is upon us, it's time to start looking at how we can improve these, so that it can swiftly be implemented and included in future releases.
I have a proof-of-concept somewhere that checked a PKGBUILD for "build_module" instead of "build". If found, it runs it once for each kernel installed on the system (checking pacman first to make sure it is a real package and not a custom kernel).
Couple this with repo-add which gets all information from the package (and does not need to know about the PKGBUILD) and this would be a real straightforward fix to building multiple modules with one PKGBUILD.
Now the *real* question is - how do we install them? I can think of a decent use-case:
$ pacman -S ndiswrapper - ndiswrapper is no longer a package. It is a group. Each package has a setting somewhere (TYPE="module" ??) indicating that this is a module. Pacman then loops through the group, if a packahe TYPE is "module", it checks to see if the kernel is installed. If it is, it adds it to the target list. - so the result would install ndiswrapper-ARCH, ndiswrapper-beyond, and ndiswrapper-thinkpad on my machine.
One problem I can think of is as follows: pacman -S ndiswrapper - install ndiswrapper-ARCH
pacman -S kernel26beyond - this should ALSO install ndiswrapper-beyond at the same time
I'm not sure how to handle this... some actual empty package named "ndiswrapper" could be installed, with the type= set to "module". That could be used to check for deps and things of that nature when upgrading or installing a new kernel...
Ideas? Thoughts?
Hm. I like this idea. I have a simpler solution mey be useful for other packages too: ndiswrapper - virtual package that contains depends=('ndiswrapper-arch' 'ndiswrapper-suspend2' 'ndiswrapper-ck' 'ndiswrapper-beyond') Note that all module packages for kernel26 get "-arch" preffix to state that they are for default arch kernel. Then ndiswrapper-beyond PKGBUILD contains requires=('kernel26beyond' 'ndiswrapper') Note "requires" variable. How is this different from "depends"? "Requires" means kernel26beyond _must_ be already present on system or is going to be installed with current -S operation, otherwise ndiswrapper-beyond will be silently ignored when user does -S ndiswrapper. (Why requires contain ndiswrapper too? This is to make sure ndiswrapper-beyond won't be installed without ndiswrapper. See the bottom of this message for more details.) Simplified showcase: # pacman -Qs kernel current/kernel26-2.6.20.1-2 # pacman -S ndiswrapper Targets: ndiswrapper-1.x-1 ndiswrapper-arch-1.37-2 Install [Y/n]? n ndiswrapper-1.x-1 is a dummy package exactly like audacious-1.x-1 and has depends=('ndiswrapper-arch' 'ndiswrapper-suspend2' 'ndiswrapper-ck' 'ndiswrapper-beyond') Note that pacman doesn't want to install ndiswrapper-beyond which has requires=('kernel26beyond') # pacman -S kernel26beyond ndiswrapper Targets: ndiswrapper-arch-1.37-2 ndiswrapper-beyond-1.34-2 Install [Y/n]? n # pacman -S ndiswrapper Targets: ndiswrapper-1.x-1 ndiswrapper-arch-1.37-2 Install [Y/n]? Y Now we have ndiswrapper installed but only for kernel26. Why only for kernel26? Because pacman silently ignores dependencies of currently installed packages that don't satisfy their requires field (note that this is valid for packages that are installed as dependencies _only_, for packages that are going to be installed explicitly - see the bottom of this message). OK, lets install kernel26beyond now. # pacman -S kernel26beyond Targets: kernel26-beyond-2.6.19.beyond2-1 Install [Y/n]? Y Here pacman doesn't install ndiswrapper-beyond (we may modify pacman to check each installed package that depends on package with requires field, but I dunno it's worth to implement this because of solution below). But then we do -Su and get Targets: kernel26-ndiswrapper-beyond-1.34-2 Here pacman checks all missed dependencies and finds that ndiswrapper's dependency ndiswrapper-beyond can now be installed. My explanation may look too longm but the principle is simple. What do you think about this? The "requires" field will be useful for other packages too. It will help to avoid circle dependencies. For example: Currently we have audacious 1.x-1 package which has depends=('audacious-player' 'audacious-pugins') while audacious-plugins has depends=('audacious-player>=1.3.0' ...). There are also other packages that have this issue (though not all of them has such virtual package). Surely audacious-plugins depends on audacious-player, but in fact audacious-player depends on audacious-plugins too (correct me if I'm wrong; but anyway such sitiuation surely exists for other packages too). To avoid circle dependency a virtual package was created. With requires field everything is simpler: audacious has depends=('audacious-plugins') (note: here audacious is current audacious-player, virtual audacious-1.x-1 package doesn't exist) audacious-plugins has requires=('audacious') Lets see what will happen when user tries to install audacious-plugins and audacious on clear system: # pacman -S audacious Targets: audacious-1.3.0-3 audacious-plugins-1.3.0-3 # pacman -S audacious-plugins audacious-plugins requires the following packages to be installed first: audacious-1.3.0-3. Install them first [Y/n]? Y Targets: audacious-1.3.0-3 audacious-plugins-1.3.0-3 Note that audacious is installed explicitly and audacious-plugins as a dependency in _both_ cases. So requires can work quite like depends too (note, however, that package cannot be in both requires and depends at the same time). Now lets see how this would work with ndiswrapper-beyond on a system with kernel26 only. # pacman -S ndiswrapper-beyond ndiswrapper-beyond requires the following packages to be installed first: kernel26-beyond-2.6.19.beyond2-1 ndiswrapper-1.x-1. Install them first [Y/n]? Y Targets: kernel26-beyond-2.6.19.beyond2-1 ndiswrapper-1.x-1 kernel26-ndiswrapper-beyond-1.34-2 See. ;-) I hope I clearly explained all details of requires functionality here. Implementing this will require some work on improving dependencies handling (pacman 3.1 or 3.2?), but it will allow to solve kernel/modules installing/upgrading/removing issues, circular dependencies and probably other issues too. What do you think about this? I would like to copy/paste this as a FR. -- Roman Kyrylych (Роман Кирилич)