[Apt-Rpm] multiple good providers, how does apt pick the right one?

[Panu Matilainen]

On Fri, 22 Feb 2008, Vincent Danen wrote:
>>>> One possibility might be adding a lua slot into the provider selection, 
>>>> that'd allow building in special policies for things that need it (would 
>>>> help dealing with kernel module packages a lot for example), with 
>>>> possibility to go interactive when necessary / appropriate etc.
>>> 
>>> I suspect you wouldn't have time to do anything like that soon, right?
>> 
>> I'm actually looking it right now :)
>
> Oh, lucky me.  =)
>
>> What's needed is lifting the guts of virtual package handling logic from 
>> apt-get's TryToInstall() into libapt-pkg's MarkInstall() and a callback 
>> system for programs to handle the selection as they wish (eg if Lua 
>> "policy" hook doesn't provide selection automatically, synaptic could show 
>> a popup window, apt-get/shell could ask similarly to what it does now when 
>> you attempt to directly install a virtual provide). Doesn't seem 
>> astronomically hard.
>
> Not to you, perhaps.  =)  Glad you're looking at it and not me.

Doesn't *seem* .. but there's always something unexpected.
The good news is that I got a very very rough first cut "working" here:

[root at turre cmdline]# ./apt-get install 
/home/pmatilai/rpmbuild/RPMS/task-ftp-0.1-1.lorg.noarch.rpm
Reading Package Lists... Done
Building Dependency Tree... Done
Selecting task-ftp for 
'/home/pmatilai/rpmbuild/RPMS/task-ftp-0.1-1.lorg.noarch.rpm'
Package ftpserver is a virtual package provided by:
1. proftpd
2. pure-ftpd
Select one to install:
2
The following extra packages will be installed:
    mysql-libs (5.0.45-6.fc8)
    postgresql-libs (8.2.6-1.fc8)
    pure-ftpd (1.0.21-13.fc8)
    task-ftp (0.1-1.lorg)

This is a new Lua hook that runs whenever there are multiple providers for 
a dependency. Which is precisely what we want. The bad news is that if it 
doesn't select anything, later Lua scripts in DoInstall() will cause apt 
to crash. Quite possibly it ends up with nested calls to Lua messing up 
it's global state or something, didn't get that far yet.

Whether it's reasonably possible to have Lua-hook in the lowlevel depsolve 
logic remains to be seen, but a C++-level callback shouldn't have such 
problems. It'd be sad if Lua can't be used but (optional) app-specific 
callback would still enable what you want, so not all hope is lost anyway 
:)

Oh, sorry but no patches to try out yet, this is too hacky and crash-happy 
atm...

 	- Panu -