[packagekit] PackageKit Apt support

[Daniel Nicoletti]

>Would packagesPendingConfiguration imply an ErrorCode and a requeue?

No, it would imply asking a helper app, since to show debconf
dialogs we need to block

>> Now the gui to can Call a helper app that deals with that Or
>> ask the question itself and send the replies to the backend.
>> The backend just need to move the new config over the old one.
>
>Right, so you're looking to add a ManualEditRequired signal to the
>daemon, which can have parameters such as "package_id", "filename",
>"other data" where other data is likely to be very distro specific,
>but can just be a filename with the description and what to do to fix
>it.

well the dialog looks like:
You or a script updated /etc/...foo.conf, do you want to keep
your custom conf or install the new one?
[NEW ONE] [Keep Mine]

this might happen for several files in an upgrade.

>You don't want to tell the user "In doing this update you are going to
>have to edit xorg.conf" that's broken in so many ways. At the end of
>the transaction, just show one modal dialog box with a list of files
>that need attention.

That's not what simulate would be for, just resume:
install 
- a
- b
remove
- y
- z
upgrade
- p
- q

>What if a backend can do GetDepends and not GetRequires? There's no
>way of saying "i support simulate(install) but not simulate(remove)".

pk-transaction.c 1853
    /* not implemented yet */
    if (transaction->priv->backend->desc->get_depends == NULL) {
        error = g_error_new (PK_TRANSACTION_ERROR, PK_TRANSACTION_ERROR_NOT_SUPPORTED,
                     "GetDepends not yet supported by backend");
        pk_transaction_release_tid (transaction);
        pk_transaction_dbus_return_error (context, error);
        return;
    }
--------------------------
with that we could say simulate remove not implemented yet.
But, if this is a problem, i suggest:
simulate_install
simulate_remove
simulate_upgrade
simulate_system_upgrade

Much cleaner api IMO. Easier for GUI folks to know they have to call it befor
triggering the transaction.

ALSO this could have a benefit of being able to emit download size, installed size
so we can check if it's too much for GSM ..

Daniel




----- Mensagem original ----
De: Richard Hughes <hughsient at gmail.com>
Para: PackageKit users and developers list <packagekit at lists.freedesktop.org>
Enviadas: Segunda-feira, 15 de Junho de 2009 13:41:42
Assunto: Re: [packagekit] PackageKit Apt support

On Mon, Jun 15, 2009 at 4:40 PM, Daniel
Nicoletti<dantti85-pk at yahoo.com.br> wrote:
> For Debconf dialogs I've found that as python apt
> does use the Non-interactive mode, BUT in this mode
> some packages fail (ie java-jre6).
> The solution is simple, create a new PackageKit method
> packagesPendingConfiguration(pkgs...), and emit, the client
> GPK or KPK will call the a helper app that will show the
> debconfs to the user and he will be happy :D, additionally
> it could have a pool (maybe implemented in the backend)
> so the user can be warned if non-configured packages are
> still pending.

Would packagesPendingConfiguration imply an ErrorCode and a requeue?

> Conffiles, this one happens when you or a script changed
> the .conf file of a give app, then when installing a newer version
> of it might conflict, as we can't wait for the user to reply immediatly
> we can again let that be done later.
> The solution is detect a conffile call (simple) and automattically answer the
> default "keep the current version", and store the file
> at the end  of the installation emit packageConfigChanges(file, maybe files).

I think that's up to the backend what to do.

> Now the gui to can Call a helper app that deals with that Or
> ask the question itself and send the replies to the backend.
> The backend just need to move the new config over the old one.

Right, so you're looking to add a ManualEditRequired signal to the
daemon, which can have parameters such as "package_id", "filename",
"other data" where other data is likely to be very distro specific,
but can just be a filename with the description and what to do to fix
it.

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

You don't want to tell the user "In doing this update you are going to
have to edit xorg.conf" that's broken in so many ways. At the end of
the transaction, just show one modal dialog box with a list of files
that need attention.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>.
> 1. The user wan't to update k3b 1.5 to 2.0.
> simulate(UPDATE_ROLE, pkg_ids);

No. GetDepends should just return libblueraydisc.

> 2. The user wants to remove libdvdread.
...
> 1 remove
> - liblow-level-dvd
> 1 new install
> - libcss

As i said on IRC, asking users to agree to install a package when they
want to remove another package is pretty crazy. From a user
interaction point of view it blows goats big style.

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

Don't make packages conflict with each other. Use the alternatives system.

> OK, i hope i was clear enough that getDepends and getRequired both in recursive
> don't fit all the cases in apt, i really believe others systems such as yum would
> have problems like these too.

Sure, GetDepends isn't meant to be a sneak-preview of the transaction,
it's designed to find out how many extra packages would need to be
downloaded.

> This proposed CHANGE is really no big deal for backends

Well, only apt would use this method. There's no way of doing simulate
for conary, portage, box, opkg or razor. I've not looked at the rest
in any detail.

> what all of then would need to do
> simulate(role, pkgs_id)
> {
> switch(role) {
> case install:
>       get_requires(pkgs_id)
> case remove:
>       get_depends(pkgs_id)
> case update:
>    do nothing
> }

What if a backend can do GetDepends and not GetRequires? There's no
way of saying "i support simulate(install) but not simulate(remove)".

> Ok, why this is important?
> because with this Debian users don't need to
> go to the CMD line to see what's going to happen
> in any of those cases.

If you're removing or changing something like glibc then i think it's
okay to tell the novice user it's impossible without going to the
command line.

> I can try to implement this method but I want
> Richard's approval and help and/or ideas on how
> to finish this.

I don't think we want this method. Adding a method is painful for the
GUI users and the backend users and not something I want to do without
more justification than this, sorry.

> Really if all this could be done I bet soon enough
> Pk would be available to Debian/Ubuntu and be much
> more welcomed :D

The biggest hurdle for PackageKit and Debian working well is for the
PackageKit folks (me) to realize that apt is much more powerful than
the other backends, and for the Debian guys to realize that PackageKit
is not designed to be powerful, but to be easy to use.

Richard.
_______________________________________________
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