[packagekit] Resolve method

[Tim Lauridsen]

Richard Hughes wrote:
> On Tue, 2007-10-02 at 15:14 -0400, Elliot Peele wrote:
>   
>> I was just using OpenOffice.org as an example. rPath Linux 1 doesn't
>> have a 64bit version of OpenOffice.org for instance because it didn't
>> build 64bit at the time that we released.
>>     
>
> Ahh, gotcha.
>
>   
>> The point was if a 32bit application on a 64bit machine requests that
>> PackageKit installs another package, it may need to be compatible with
>> the requesting application.
>>     
>
> Ick ick ick. Can't we just add a filter or something?
>
>   
>> Do we return the latest version for both arches and let PackageKit
>> figure it out?
>>     
>
> Nope, PackageKit shouldn't contain the multiarch or versioning logic.
> That's where rcd went wrong.
>
>   
>> Just returning the latest version doesn't work in the multiarch world
>> that we live in. :)
>>     
>
> What is the usecase for this? firefox.i386 wants gnash.i386 on an
> otherwise x64 system? Would libflash.x64 even exist in the repos or be
> installable?
>
> The reason I want an example is that it's pointless discussing
> theoretical cases that make the daemon a lot more complex when it's just
> theory. Plus, we can get to a solution more quickly without
> analogies ;-)
>
> Richard.
>
>
>
>
> _______________________________________________
> PackageKit mailing list
> PackageKit at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/packagekit
>   
I agree with Richard the multilib shall be handled in the backend, 
different backend and distributions handles multilib in different ways, 
so there is no "This is the right way to do multilib".

Tim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/packagekit/attachments/20071003/d02e2a79/attachment-0004.htm>