[packagekit] Dependencies resolution

[Daniel Nicoletti]

>> Richard proposed guessing getDepends when recursive is enabled
>> and emit packages to be removed however in src/pk-transaction.c:823
>> it simply drops the package (which imo it's a bit of duplication since
>> we should already do that in the backend).
>
>What was Richards statement here exactly? Sorry but I don't fully
>understand the above abstract.

He proposed using the code we have in the normal way but emiting packages
to be removed.
like getDepends("~installed", pkgfoo, true)
but as "~installed" is set pk-transaction.c simply ignores
INSTALLED packages.

>I don't see any need to add any additional filters or enums. There is
>already a set of enums to indicate a changing state:
>PK_ENUM_INFO_(INSTALLING|REMOVING|UPDATING)

The above could be a sollution since INSTALLING is not INSTALLED
but that's grammar mistake.
Since a Package to be removed is to be removed not removing.
Removing is only used when it's happening..
So:
libfoo AVAILABLE means to be INSTALLED
libbar INSTALLED means to be REMOVED
libxxx NORMAL means a NORMAL update.

>In the long run having better named methods could help. I always have to
>think about the behavior of GetRequires and GetDepends.

I agree, but i can't find a better naming :P

Daniel.




----- Mensagem original ----
De: Sebastian Heinlein <glatzor at ubuntu.com>
Para: PackageKit users and developers list <packagekit at lists.freedesktop.org>
Enviadas: Segunda-feira, 13 de Julho de 2009 18:23:36
Assunto: Re: [packagekit] Dependencies resolution

Am Montag, den 13.07.2009, 07:23 -0700 schrieb Daniel Nicoletti:

> A simple use case would be one wants to install
> exim4 which conflicts with (postfix|qmail|sendmail)
> so if one of them is already installed it'll be asked to
> remove.
> 
> So what we (apt and portage) need is a way to resolve
> dependencies in a way that we can display packages
> to be removed. They are rare but not impossible and
> the command line is NOT an option for me.

I agree that this is really a problem. Also think about the case if an
update requires additional packages to be installed. This happens from
time to time and currently there is no way to install these security
updates with (k)packagekit.

> Richard proposed guessing getDepends when recursive is enabled
> and emit packages to be removed however in src/pk-transaction.c:823
> it simply drops the package (which imo it's a bit of duplication since
> we should already do that in the backend).

What was Richards statement here exactly? Sorry but I don't fully
understand the above abstract.

> My idea them as Richard don't want to break API with "simulate_install"
> and alike, is to add three new filters (with better naming):
> 
> PK_FILTER_ENUM_TO_INSTALL
> PK_FILTER_ENUM_TO_REMOVE
> PK_FILTER_ENUM_TO_UPDATE

I don't see any need to add any additional filters or enums. There is
already a set of enums to indicate a changing state:
PK_ENUM_INFO_(INSTALLING|REMOVING|UPDATING)

Richard, I would propose to change the convention of GetRequires and
GetDepends here. Updates should be covered by the GetDepends call with
the version number of update.

In the long run having better named methods could help. I always have to
think about the behavior of GetRequires and GetDepends.

Cheers,

Sebastian



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