[packagekit] Resolve method

[Ken VanDine]

Conary matches the system arch and installs the right version.

On 10/3/07, Richard Hughes <hughsient at gmail.com> wrote:
> On Wed, 2007-10-03 at 11:35 -0400, Elliot Peele wrote:
> > On Wed, 2007-10-03 at 09:02 +0200, Tim Lauridsen wrote:
> > > Richard Hughes wrote:
> > > > 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 ;-)
> > > >
> > > 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".
> >
> > I agree that the backend should handle multilib, however I think that we
> > are going to run into compatibility issues when applications start being
> > able to install other packages.
>
> Sure, but as soon as you add architecture info into the abstraction
> something has to make a choice; packagekit is not clever enough to do
> this; and the user isn't going to care.
>
> I would love to see my mum's face when she sees this:
>
> "You wanted to install the borwser plugin. Do you want to use the x86_64
> package or the x86 package?"
>
> > A real world example of this case:
> >
> > On an x86_64 system I have x86 firefox. Firefox requests mplayerplug-in,
> > we have both x86 and x86_64 versions of mplayerplug-in available. How
> > does the backend know which arch to install?
>
> If I type in "conary install mplayerplug-in" (or whatever the command
> is), what gets installed?
>
> Richard.
>
>
> _______________________________________________
> PackageKit mailing list
> PackageKit at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/packagekit
>


-- 
Ken VanDine
http://ken.vandine.org