[pacman-dev] Handling modules

[Roman Kyrylych]

2007/3/9, Aaron Griffin <aaronmgriffin at gmail.com>:
> On 3/9/07, Aaron Griffin <aaronmgriffin at gmail.com> wrote:
> > On 3/9/07, James <iphitus at 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 (Роман Кирилич)