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

[Vincent Danen]

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

>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?  =)

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

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.

-- 
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/20080221/0c378f32/attachment-0003.pgp>