[packagekit] PackageKit Apt support

[Daniel Nicoletti]

>The idea of simulate() to fix this worries me, because it implies that
>any two runs of the transaction at any points in time must always do the
>same thing ... which looks like a giant race condition to me, and is
>bound to fail eventually (although much less so than PK guessing what
>the transaction will be).

Yes, but again this has the same problem as in get_depends,
what if while looking at a package deps the cache is updated
and others packages are also installed as new deps?




----- Mensagem original ----
De: James Antill <james at fedoraproject.org>
Para: PackageKit users and developers list <packagekit at lists.freedesktop.org>
Enviadas: Segunda-feira, 15 de Junho de 2009 13:38:39
Assunto: Re: [packagekit] PackageKit Apt support

On Mon, 2009-06-15 at 08:40 -0700, Daniel Nicoletti wrote:
> Hi list,
> 
> After some discussion today on irc, here's an email
> resuming things.
[...]
> - Properly showing what is going to happen.
[...]
> The last one and very important imo is to properly shows
> what is going to happen. To understand this one I'll present the
> same use cases I proposed in my lasts "simulate" emails:
> 
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>.
> 1. The user wan't to update k3b 1.5 to 2.0.
> Today we do updatePackage(k3b).
> PROBLEM: the new k3b 2.0 no longer depends on cdrdao,, and it depends on
> dvdrw-tools > 1.0, and it now depends on blue-ray-disk.
> So the way PK work today, the user won't see that dvdrw-tools
> must and will be update, neither he sees that the unused dep (cdrdao) will be removed
> (of course if it's not being used by any other package) AND that a new package (blue-ray-disk)
> will be installed.
> Proposed:
> simulate(UPDATE_ROLE, pkg_ids);

Why do we need this extra call? This is for user notification, yeh? So
what's the current call to get that info.? ... simulate(X)/X seems like
a bad choice. What you _really_ want is something like:

transaction start
update blah
user notification =>
  cancel transaction
  commit transaction

yum may eventually do the above (with the remove-leaves plugin, it may
already), and in general I don't think you can guess what yum will do in
an update transaction without running the transaction.

> 2. The user wants to remove libdvdread.
> PROBLEM: the mplayer pkg depends on at least one dvd reader,
> which can be libdvdread OR libcss, libdvdread also installed liblow-level-dvd
> which was marked as Automatic installed (when we installed)
> and no other installed app is using this lib.
> Again the way Pk work today we would do get_required_by(RECURSIVE)
> and we would see what packages libdvdread depends, we would find mplayer,
> but mplayer can use libcss so we can ask for install,
> and we would not find that the unused lib-low-leve-dvd will be automatic
> removed (as no other package is using it).
> Proposed:
> simulate(REMOVE_ROLE, pkg_ids);

Doing the above seems a bit weird, and yum is unlikely to ever do
that ... but again, I'm 99% sure that PK is wrong now for yum if it
guesses what happens in a remove transaction by calling
get_required_by() on it's own.

> 3- The user wants to install firefox
> PROBLEM: firefox conflics with Internet Explorer :P

In yum we just say "firefox conflicts with IE, can't install". But
again, guessing what happens in an install transaction by calling
get_depends() will fail.

The idea of simulate() to fix this worries me, because it implies that
any two runs of the transaction at any points in time must always do the
same thing ... which looks like a giant race condition to me, and is
bound to fail eventually (although much less so than PK guessing what
the transaction will be).

-- 
James Antill - james at fedoraproject.org
"I'd just like to see a realistic approach to updates via
packages." -- Les Mikesell
_______________________________________________
PackageKit mailing list
PackageKit at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/packagekit



      Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com