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

[Panu Matilainen]

On Thu, 21 Feb 2008, Vincent Danen wrote:

> * [2008-02-21 15:22:45 +0200] Panu Matilainen wrote:
>
>>> I've got a question here about how apt picks from multiple good
>>> providers of a dependency.
>>> 
>>> For instance, I want to have meta-packages that are nothing but requires
>>> on packages.  I have a task-mail package which has requires on
>>> imaps-server and pops-server, and this is provided by both dovecot and
>>> courier-imap.
>>> 
>>> apt isn't letting me choose, however, which one to install.  It's
>>> arbitrarily selecting courier-imap, so it seems to be
>>> alphabetical-based, which is ok, but coming from something like urpmi
>>> where it asks you to pick which package to install, that was the
>>> behaviour I was hoping to get.
>>> 
>>> For instance, if neither courier-imap nor dovecot is installed and a
>>> user does "apt-get install task-mail", I want it to ask them which they
>>> want installed.  Another example would be for a virtual provides of
>>> "smtpdaemon"... both postfix and exim provide it, but I suspect that apt
>>> will arbitrarily pick exim, which isn't what I want.
>>> 
>>> Is there a way to accomplish this with apt?
>> 
>> I'm afraid not. Like you noticed, when a package depends on a virtual 
>> provide, whatever matches the provide first is picked. OTOH when you try to 
>> install a virtual provide with several provides directly, it'll ask you to 
>> choose one. Inconsistent, annoying and limiting :-/
>
> Hmmm... let me see if I get this.  If I had a requires on "smtpdaemon
> postfix exim" then it would let me pick?  But not just on "smtpdaemon"?
>
> Annoying, yes, but I could work with it until something better is
> implemented.  It's not like I have a lot of these packages.

Nope. A dependency on virtual provide is always selected automatically, 
but if you do "apt-get install <virtual provide>" it'll ask:

[root at turre cmdline]# ./apt-get install ftpserver
Reading Package Lists... Done
Building Dependency Tree... Done
Package ftpserver is a virtual package provided by:
   pure-ftpd 1.0.21-13.fc8
   proftpd 1.3.1-1.fc8
You should explicitly select one to install.
E: Package ftpserver is a virtual package with multiple good providers.

[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'
The following extra packages will be installed:
    proftpd (1.3.1-1.fc8)
    task-ftp (0.1-1.lorg)

... etc.

>
>> The problem is that way too much logic is built into apt-get itself instead 
>> of libapt-pkg: on direct install of virtual provide, it's apt-get that 
>> "manually" looks for the providers, but when processing a dependency, it's 
>> libapt-pkg which just picks whatever has highest priority.
>> 
>> I remember having had a look at this at some point, possibly while 
>> scratching head over handling multilib issues, and IIRC strange things 
>> started happening when messing with MarkInstall() logic. But that's a long 
>> time ago and memory is hazy...
>
> Ahhh... thus the desire to break more out of the main program and into
> libs, right?  =)

Yes, very much so...

>> 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 :)

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.

> If I can use a kludge/workaround for the time being as you expressed
> above, then that's fine... I can work with that.  Something more elegant
> would be nice (this is one thing where urpmi has apt beaten), but if
> there is a bit of a hackish workaround, I can live with it.

No workaround at present I'm afraid :-/ Lets see if I can manage to steal 
a few hours of hacking time this weekend, fixing this would help several 
different problems.

 	- Panu -