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

[Vincent Danen]

* [2008-02-22 22:03:10 +0200] Panu Matilainen wrote:

[...]
>>>> 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.

Oh!  I get it.  Hmmm... yeah, that's not so helpful.

>>> 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...

Gotchya.  Wish I could help you with that, but I'm a shell monkey, and
my C skills are pretty sub-standard.  =(

>>> 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.

>> 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.

That would be awesome.  Thanks so much, Panu.  Looking forward to having
something to play with if you can manage to scrape the time together.

-- 
Vincent Danen @ http://linsec.ca/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.laiskiainen.org/pipermail/apt-rpm-laiskiainen.org/attachments/20080222/70fb4f28/attachment-0003.pgp>