headers
Richard Hughes | 3 Jun 2012 15:48
Picon

Adding support for "prepare" in transaction_flags

Hi all,

The new transaction_flags has a new bit that might be set. If the
PREPARE bit is set, then it's important that the transaction that the
backend has been asked to do is setup, all the files downloaded, but
changes actually not made. This is different to simulate, as simulate
doesn't actually download packages.

We're intending to use this heavily in GNOME 3.6, so it's kinda
important to implement in the next few months. I've done zif, and I'll
do yum on Monday with Nils.

Any questions, yell. Thanks.

Richard.
Permalink | Reply |
headers
Fabio Erculiani | 3 Jun 2012 16:36
Favicon
Gravatar

Re: Adding support for "prepare" in transaction_flags

It would be nice if you maintained a list of backend API changes from
0.6.x to 0.7.x somewhere. Not everybody can keep up with the mailing
list on a daily/weekly basis and going through random emails is not
really comfortable ;-)

Thanks,
--

-- 
Fabio Erculiani
Permalink | Reply |
headers
Richard Hughes | 3 Jun 2012 16:40
Picon

Re: Adding support for "prepare" in transaction_flags

On 3 June 2012 15:36, Fabio Erculiani <lxnay@...> wrote:
> It would be nice if you maintained a list of backend API changes from
> 0.6.x to 0.7.x somewhere. Not everybody can keep up with the mailing
> list on a daily/weekly basis and going through random emails is not
> really comfortable ;-)

Makes sense, give me a few minutes.

Richard.
Permalink | Reply |
headers
Richard Hughes | 3 Jun 2012 17:04
Picon

Re: Adding support for "prepare" in transaction_flags

On 3 June 2012 15:40, Richard Hughes <hughsient@...> wrote:
> Makes sense, give me a few minutes.

Pull master, and have a quick read of backends/PORTING.txt

Richard.
Permalink | Reply |
headers
Matthias Klumpp | 3 Jun 2012 17:21
Gravatar

Re: Adding support for "prepare" in transaction_flags

Hi!
Maybe I missed something, but shouldn't this be a porting-guide from
PK 0.7.x to 0.8.x? ;-)
(Since 0.7.x is new stable)
Cheers,
   Matthias

2012/6/3 Richard Hughes <hughsient@...>:
> On 3 June 2012 15:40, Richard Hughes <hughsient@...> wrote:
>> Makes sense, give me a few minutes.
>
> Pull master, and have a quick read of backends/PORTING.txt
>
> Richard.
> _______________________________________________
> PackageKit mailing list
> PackageKit@...
> http://lists.freedesktop.org/mailman/listinfo/packagekit
Permalink | Reply |
headers
Richard Hughes | 3 Jun 2012 17:23
Picon

Re: Adding support for "prepare" in transaction_flags

On 3 June 2012 16:21, Matthias Klumpp <matthias@...> wrote:
> Maybe I missed something, but shouldn't this be a porting-guide from
> PK 0.7.x to 0.8.x? ;-)

Bahh. Too much code this weekend -- can you commit a fix please :)

Thanks,

Richard.
Permalink | Reply |
headers
Matthias Klumpp | 3 Jun 2012 17:39
Gravatar

Re: Adding support for "prepare" in transaction_flags

Changed ;-)
Do you have any news about the idea of merging RemovePackages() and
InstallPackages() into one modify-task?

  -- Matthias

2012/6/3 Richard Hughes <hughsient@...>:
> On 3 June 2012 16:21, Matthias Klumpp <matthias@...> wrote:
>> Maybe I missed something, but shouldn't this be a porting-guide from
>> PK 0.7.x to 0.8.x? ;-)
>
> Bahh. Too much code this weekend -- can you commit a fix please :)
>
> Thanks,
>
> Richard.
> _______________________________________________
> PackageKit mailing list
> PackageKit@...
> http://lists.freedesktop.org/mailman/listinfo/packagekit
Permalink | Reply |
headers
Richard Hughes | 3 Jun 2012 17:42
Picon

Re: Adding support for "prepare" in transaction_flags

On 3 June 2012 16:39, Matthias Klumpp <matthias@...> wrote:
> Do you have any news about the idea of merging RemovePackages() and
> InstallPackages() into one modify-task?

I'm in two minds about this. One is that it's probably a good idea for
an edge case, but the other is then we also have to deal with
INSTALL|REMOVE|UPDATE as well, which starts to make the API look a
little odd. I also can't come up with a good method name[1] and am
worried that a lot of backends might not be able to do this.

Richard.

[1] InstallRemoveUpdatePackages() is not a good name :)
Permalink | Reply |
headers
Daniel Nicoletti | 3 Jun 2012 20:05
Picon
Gravatar

Re: Adding support for "prepare" in transaction_flags

2012/6/3 Richard Hughes <hughsient@...>:
> On 3 June 2012 16:39, Matthias Klumpp <matthias@...> wrote:
>> Do you have any news about the idea of merging RemovePackages() and
>> InstallPackages() into one modify-task?
>
> I'm in two minds about this. One is that it's probably a good idea for
> an edge case, but the other is then we also have to deal with
> INSTALL|REMOVE|UPDATE as well, which starts to make the API look a
> little odd. I also can't come up with a good method name[1] and am
> worried that a lot of backends might not be able to do this.
>
> Richard.
>
> [1] InstallRemoveUpdatePackages() is not a good name :)
Yes, IMO this is the main problem a good name :P aptd had one
that wasn't that bad but I can't recal.

BTW can you change this enum name to DOWNLOAD_ONLY?
I was thinking about this a lot these days because of that
systemd link, and now that you added I'd just change the name.

Best
Permalink | Reply |
headers
Richard Hughes | 3 Jun 2012 20:28
Picon

Re: Adding support for "prepare" in transaction_flags

On 3 June 2012 19:05, Daniel Nicoletti <dantti12@...> wrote:
> BTW can you change this enum name to DOWNLOAD_ONLY?
> I was thinking about this a lot these days because of that
> systemd link, and now that you added I'd just change the name.

I considered ONLY_DOWNLOAD initially, but I wanted a name that implied
more than that. PREPARE is meant to mean download and get everything
ready, so in Zif I could move the downloaded files to a different
directory, or pack them in a tarball, or even prepare a solv file for
depsolving. Basically "prepare the transaction for later resuming".

That said, if the consensus is "prepare is a silly name" then I'll change it :)

Richard.
Permalink | Reply |
headers
Daniel Nicoletti | 3 Jun 2012 20:36
Picon
Gravatar

Re: Adding support for "prepare" in transaction_flags

Ok, it's just that for apt it would mean download only...

2012/6/3 Richard Hughes <hughsient@...>:
> On 3 June 2012 19:05, Daniel Nicoletti <dantti12@...> wrote:
>> BTW can you change this enum name to DOWNLOAD_ONLY?
>> I was thinking about this a lot these days because of that
>> systemd link, and now that you added I'd just change the name.
>
> I considered ONLY_DOWNLOAD initially, but I wanted a name that implied
> more than that. PREPARE is meant to mean download and get everything
> ready, so in Zif I could move the downloaded files to a different
> directory, or pack them in a tarball, or even prepare a solv file for
> depsolving. Basically "prepare the transaction for later resuming".
>
> That said, if the consensus is "prepare is a silly name" then I'll change it :)
>
> Richard.
> _______________________________________________
> PackageKit mailing list
> PackageKit@...
> http://lists.freedesktop.org/mailman/listinfo/packagekit
Permalink | Reply |
headers
Richard Hughes | 3 Jun 2012 20:38
Picon

Re: Adding support for "prepare" in transaction_flags

On 3 June 2012 19:36, Daniel Nicoletti <dantti12@...> wrote:
> Ok, it's just that for apt it would mean download only...

Same for yum and zif, so you might have a point. Would anybody else do
anything else except download? What about a source distro that needs
to download, make but *not* sudo make install?

Richard.
Permalink | Reply |
headers
Daniel Nicoletti | 3 Jun 2012 20:43
Picon
Gravatar

Re: Adding support for "prepare" in transaction_flags

2012/6/3 Richard Hughes <hughsient@...>:
> On 3 June 2012 19:36, Daniel Nicoletti <dantti12@...> wrote:
>> Ok, it's just that for apt it would mean download only...
>
> Same for yum and zif, so you might have a point. Would anybody else do
> anything else except download? What about a source distro that needs
> to download, make but *not* sudo make install?
hmm dunno but I'd think you wouldn't like it to eat you CPU compiling,
and just install later (which would be the fastest part I think).
Permalink | Reply |
headers
Matthias Klumpp | 3 Jun 2012 20:56
Gravatar

Re: Adding support for "prepare" in transaction_flags

I really liked the suggestion for all stuff like RemovePackages()
InstallPackages() etc. to just enqueue the actions and one new
"Commit()" signal to really apply the changes.
This would solve the issues, but to implement it properly, backend and
frontend APIs would have to be broken, which is not ideal.

2012/6/3 Daniel Nicoletti <dantti12@...>:
> 2012/6/3 Richard Hughes <hughsient@...>:
>> On 3 June 2012 19:36, Daniel Nicoletti <dantti12@...> wrote:
>>> Ok, it's just that for apt it would mean download only...
>>
>> Same for yum and zif, so you might have a point. Would anybody else do
>> anything else except download? What about a source distro that needs
>> to download, make but *not* sudo make install?
> hmm dunno but I'd think you wouldn't like it to eat you CPU compiling,
> and just install later (which would be the fastest part I think).
> _______________________________________________
> PackageKit mailing list
> PackageKit@...
> http://lists.freedesktop.org/mailman/listinfo/packagekit
Permalink | Reply |
headers
Daniel Nicoletti | 3 Jun 2012 21:03
Picon
Gravatar

Re: Adding support for "prepare" in transaction_flags

2012/6/3 Matthias Klumpp <matthias@...>:
> I really liked the suggestion for all stuff like RemovePackages()
> InstallPackages() etc. to just enqueue the actions and one new
> "Commit()" signal to really apply the changes.
> This would solve the issues, but to implement it properly, backend and
> frontend APIs would have to be broken, which is not ideal.
Well right now pretty much everything is broken, even the
install/remove/update methods, so creating this method would
imo bring some goodies, I can only tell by apt, but maybe
other backends could make use of that too.
Permalink | Reply |
headers
Matthias Klumpp | 3 Jun 2012 21:22
Gravatar

Re: Adding support for "prepare" in transaction_flags

According to Richard, the problem here is that we would also
completely break all frontend APIs - if you use PkTask right now,
nothing's changed.
I think it would be worth to do it, but I'm not sure what Richard has to say ^^
(We discussed this a few hours ago on IRC, and Daniel (glatzor) also
commented on it and how they do it in aptdaemon)

2012/6/3 Daniel Nicoletti <dantti12@...>:
> 2012/6/3 Matthias Klumpp <matthias@...>:
>> I really liked the suggestion for all stuff like RemovePackages()
>> InstallPackages() etc. to just enqueue the actions and one new
>> "Commit()" signal to really apply the changes.
>> This would solve the issues, but to implement it properly, backend and
>> frontend APIs would have to be broken, which is not ideal.
> Well right now pretty much everything is broken, even the
> install/remove/update methods, so creating this method would
> imo bring some goodies, I can only tell by apt, but maybe
> other backends could make use of that too.
> _______________________________________________
> PackageKit mailing list
> PackageKit@...
> http://lists.freedesktop.org/mailman/listinfo/packagekit
Permalink | Reply |
headers
Richard Hughes | 3 Jun 2012 23:37
Picon

Re: Adding support for "prepare" in transaction_flags

On 3 June 2012 20:22, Matthias Klumpp <matthias@...> wrote:
> I think it would be worth to do it, but I'm not sure what Richard has to say ^^

I think the Commit() method makes a lot of sense. What I think we should do is:

* Create Transaction.Commit(transaction_flags)
* Add a NO_COMMIT enum to PkTransactionFlag
* Add code in *every* pk-backend-*.c that if NO_COMMIT is present in
transaction_flags then return ErrorCode(NO_SUPPORT)
* Add pk_task_set_auto_commit(PkTask *task, gboolean auto_commit),
with auto_commit by default set to TRUE.
* If auto_commit is FALSE in PkTask when we do the non-simulate
transaction then add the NO_COMMIT flag
* Encourage backends that can do delayed commit (yum, zif, aptcc, etc)
to implement NO_COMMIT and *not* call pk_backend_finished() if doing
that.
* Add support to apper/gnome-packagekit for NO_COMMIT and Commit()
once the well-supported backends have support

This means that clients that don't set the new flag on each
transaction "just work" and any that want to be clever-ass can do the
additional Commit() step :)

If this sounds like a plan, I'm happy to add the Commit() large additions.

Richard.
Permalink | Reply |
headers
Richard Hughes | 3 Jun 2012 23:40
Picon

Re: Adding support for "prepare" in transaction_flags

On 3 June 2012 22:37, Richard Hughes <hughsient@...> wrote:
> * Add code in *every* pk-backend-*.c that if NO_COMMIT is present in
> transaction_flags then return ErrorCode(NO_SUPPORT)

Actually, we don't have to do that. If a backend doesn't implement
pk_backend_commit() then we can check for NO_COMMIT for each method.

Richard.
Permalink | Reply |
headers
Matthias Klumpp | 4 Jun 2012 00:03
Gravatar

Re: Adding support for "prepare" in transaction_flags

Sounds sane to me! Thanks for thinking about this :-)
And btw, this shows how great and extensible the new TransactionFlags are!
Cheers,
   Matthias

2012/6/3 Richard Hughes <hughsient@...>:
> On 3 June 2012 22:37, Richard Hughes <hughsient@...> wrote:
>> * Add code in *every* pk-backend-*.c that if NO_COMMIT is present in
>> transaction_flags then return ErrorCode(NO_SUPPORT)
>
> Actually, we don't have to do that. If a backend doesn't implement
> pk_backend_commit() then we can check for NO_COMMIT for each method.
>
> Richard.
> _______________________________________________
> PackageKit mailing list
> PackageKit@...
> http://lists.freedesktop.org/mailman/listinfo/packagekit
Permalink | Reply |
headers
Richard Hughes | 4 Jun 2012 00:14
Picon

Re: Adding support for "prepare" in transaction_flags

On 3 June 2012 23:03, Matthias Klumpp <matthias@...> wrote:
> Sounds sane to me! Thanks for thinking about this :-)

Except we need a new name. Commit() is used quite a lot in PackageKit
internally, and a new concept with the same name makes the code as
confusing as hell. Better ideas welcome. Perhaps
Transaction.Complete(), Transaction.Exec(), Transaction.Go()?

There are also a few difficult to solve problems.
* Does Transaction.Role enum then become a Transaction.Roles bitfield,
or do we have a ROLE_COMPLETE which can mean 'any'?
* Does .Complete() need a PolicyKit authentication type?
* Do we ask for auth when we do InstallPackage() or when we do
Complete()? Or both?

> And btw, this shows how great and extensible the new TransactionFlags are!

Yes, I think so too. :)

Richard.
Permalink | Reply |
headers
Matthias Klumpp | 4 Jun 2012 00:33
Gravatar

Re: Adding support for "prepare" in transaction_flags

Hi!

2012/6/4 Richard Hughes <hughsient@...>:
> On 3 June 2012 23:03, Matthias Klumpp <matthias@...> wrote:
>> Sounds sane to me! Thanks for thinking about this :-)
>
> Except we need a new name. Commit() is used quite a lot in PackageKit
> internally, and a new concept with the same name makes the code as
> confusing as hell. Better ideas welcome. Perhaps
> Transaction.Complete(), Transaction.Exec(), Transaction.Go()?
Transaction.Execute() sounds good, as "complete" would be more like a
state name ("transaction is completed")
Go() is also okay.

> There are also a few difficult to solve problems.
> * Does Transaction.Role enum then become a Transaction.Roles bitfield,
> or do we have a ROLE_COMPLETE which can mean 'any'?
Bitfield sounds good, if there are benefits in doing that - is it
important to know what the transaction did?

> * Does .Complete() need a PolicyKit authentication type?
No, probably not.

> * Do we ask for auth when we do InstallPackage() or when we do
> Complete()? Or both?
I'd ask when doing InstallPackages() - if user has no authorization to
do InstallPackages(), nothing can be executed on Complete() - Of
course, frontends should be able to handle that.

(Just my first thoughts about that)
(Continue reading)

Permalink | Reply |
headers
Sebastian Heinlein | 4 Jun 2012 07:34
Favicon

Re: Adding support for "prepare" in transaction_flags

Am Montag, den 04.06.2012, 00:33 +0200 schrieb Matthias Klumpp: 
> Hi!
> 
> 2012/6/4 Richard Hughes <hughsient@...>:
> > On 3 June 2012 23:03, Matthias Klumpp <matthias@...> wrote:
> >> Sounds sane to me! Thanks for thinking about this :-)
> >
> > Except we need a new name. Commit() is used quite a lot in PackageKit
> > internally, and a new concept with the same name makes the code as
> > confusing as hell. Better ideas welcome. Perhaps
> > Transaction.Complete(), Transaction.Exec(), Transaction.Go()?
> Transaction.Execute() sounds good, as "complete" would be more like a
> state name ("transaction is completed")
> Go() is also okay.

In the beginning of aptdaemon I adopted the PackageKit interface design,
but introduced some changes later: I moved all the transaction role
methods (InstallPackages(), RemovePackages(), GetUpdates(), etc...) to
the main interface (which would be org.freedesktop.PackageKit in this
case), see [1].

The methods return the tid of a new transaction which already has its
role set. The methods on the transaction interface are only used to
modify the transaction. The authentication happens at the Run() call of
the transaction - this allows users to simulate transactions without
having to authenticate.

So you could have only SetHints(), Cancel(), Prepare(), Simulate() and
Run() or Commit() methods on the transaction interface. This should make
the design more clearer.
(Continue reading)

Permalink | Reply |
headers
Richard Hughes | 4 Jun 2012 09:40
Picon

Re: Adding support for "prepare" in transaction_flags

On 4 June 2012 06:34, Sebastian Heinlein <glatzor@...> wrote:
> In the beginning of aptdaemon I adopted the PackageKit interface design,
> but introduced some changes later: I moved all the transaction role
> methods (InstallPackages(), RemovePackages(), GetUpdates(), etc...) to
> the main interface (which would be org.freedesktop.PackageKit in this
> case), see [1].

I must admit, I'm a bit disappointed in how quickly the two interfaces
have diverged, especially considering how open I was do doing large
API changes in PackageKit this development cycle.

> So you could have only SetHints(), Cancel(), Prepare(), Simulate() and
> Run() or Commit() methods on the transaction interface. This should make
> the design more clearer.

Yes, but the flip side is you have to have an CommitPackages()-style
mega-method, and you loose the ability to have different argument
lists for UpdatePackages, InstallPackages, and RemovePackages, e.g.
autoremove and allow_deps, although arguably these could be in
transaction_flags.

Richard.
Permalink | Reply |
headers
Daniel Nicoletti | 4 Jun 2012 18:08
Picon
Gravatar

Re: Adding support for "prepare" in transaction_flags

> Yes, but the flip side is you have to have an CommitPackages()-style
> mega-method, and you loose the ability to have different argument
> lists for UpdatePackages, InstallPackages, and RemovePackages, e.g.
> autoremove and allow_deps, although arguably these could be in
> transaction_flags.

The good thing of doing this is that we can actually, do
little break on the client side APIs. I'd suggest the Run()
method, and NO_AUTO_RUN flag, so when the
transaction is set (ie install, remove..) have been called
we call Run().

This could also allow for having a PURGE flag so
a frontend wanting to expose this function can do so
without breaking methods...

BTW allow_deps and autoremove and "PURGE" :D
should be in the flags bitfield to let the remove method
cleaner....

Best.
Permalink | Reply |
headers
Sebastian Heinlein | 4 Jun 2012 08:16
Favicon

Re: Adding support for "prepare" in transaction_flags

Am Sonntag, den 03.06.2012, 16:03 -0300 schrieb Daniel Nicoletti: 
> 2012/6/3 Matthias Klumpp <matthias@...>:
> > I really liked the suggestion for all stuff like RemovePackages()
> > InstallPackages() etc. to just enqueue the actions and one new
> > "Commit()" signal to really apply the changes.
> > This would solve the issues, but to implement it properly, backend and
> > frontend APIs would have to be broken, which is not ideal.
> Well right now pretty much everything is broken, even the
> install/remove/update methods, so creating this method would
> imo bring some goodies, I can only tell by apt, but maybe
> other backends could make use of that too.

Aptdaemon features a CommitPackages() method (but I am also not very
happy with the name). The method accepts arrays of strings of package
names for each operation: install, update, remove, purge, downgrade.
(Optionally and in the case of downgrade mandatory a target version can
be specified [1].

As stated on IRC the benefit is that even sophisticated package managers
could use a PolicyKit driven backend without having to re-event the
wheel, yast, Synaptic etc.

We reduced the number of used policykit privileges some time ago and
only use install-or-remove-packages, install-local-file and
update-packages privileges for the basic package install/removal/upgrade
operations, see [2].

If only upgrades are requested in a CommitPackages() call we only
require the upgrade-packages privilege otherwise the
install-or-remove-packages is required. The reason is very simple:
(Continue reading)

Permalink | Reply |
headers
Anders F Björklund | 4 Jun 2012 18:14
Picon
Picon

Re: Adding support for "prepare" in transaction_flags

Richard Hughes wrote:

> On 3 June 2012 19:36, Daniel Nicoletti <dantti12@...> wrote:
>> Ok, it's just that for apt it would mean download only...
> 
> Same for yum and zif, so you might have a point. Would anybody else do
> anything else except download? What about a source distro that needs
> to download, make but *not* sudo make install?

For a source distribution, you will still have to install the build
dependencies (requiring root) in order to complete the package build.
It could of course still prepare, by downloading distfiles and patches.

--anders
Permalink | Reply |
headers
Daniel Nicoletti | 4 Jun 2012 18:25
Picon
Gravatar

Re: Adding support for "prepare" in transaction_flags

2012/6/4 Anders F Björklund <afb@...>:
> Richard Hughes wrote:
>
>> On 3 June 2012 19:36, Daniel Nicoletti <dantti12@...> wrote:
>>> Ok, it's just that for apt it would mean download only...
>>
>> Same for yum and zif, so you might have a point. Would anybody else do
>> anything else except download? What about a source distro that needs
>> to download, make but *not* sudo make install?
>
> For a source distribution, you will still have to install the build
> dependencies (requiring root) in order to complete the package build.
> It could of course still prepare, by downloading distfiles and patches.
Right, well the prepare thing would afaik still require root,
since it will download files to root writable dirs, but as you say
the make process could only work if the needed deps are satisfied,
so imo making the enum name DOWNLOAD_ONLY makes sense
since the whole make process as you say should be done in one
single step.

Daniel
Permalink | Reply |
headers
Anders F Björklund | 6 Jun 2012 11:00
Picon
Picon

Re: Adding support for "prepare" in transaction_flags

Daniel Nicoletti wrote:
>> Richard Hughes wrote:
>> 
>>> On 3 June 2012 19:36, Daniel Nicoletti <dantti12@...> wrote:
>>>> Ok, it's just that for apt it would mean download only...
>>> 
>>> Same for yum and zif, so you might have a point. Would anybody else do
>>> anything else except download? What about a source distro that needs
>>> to download, make but *not* sudo make install?
>> 
>> For a source distribution, you will still have to install the build
>> dependencies (requiring root) in order to complete the package build.
>> It could of course still prepare, by downloading distfiles and patches.
> Right, well the prepare thing would afaik still require root,
> since it will download files to root writable dirs, but as you say
> the make process could only work if the needed deps are satisfied,
> so imo making the enum name DOWNLOAD_ONLY makes sense
> since the whole make process as you say should be done in one
> single step.

Even more fun is when it starts to build the source packages at boot-time.
Maybe the source backends shouldn't be allowed*, but use .tbz2 and .txz ?
* i.e. emerge --binpkg-only and portupgrade --use-packages-only, and just
fail if no such packages have been prepared from the ebuilds and ports...

After all, there is no method to install from .src.rpm and .dsc either.
(one has to build the binary .rpm and .deb first, outside of PackageKit)

--anders
(Continue reading)

Permalink | Reply |
headers
Sebastian Heinlein | 5 Jun 2012 07:12
Picon
Favicon
Gravatar

Re: Adding support for "prepare" in transaction_flags

Am Montag, den 04.06.2012, 18:14 +0200 schrieb Anders F Björklund: 
> Richard Hughes wrote:
> 
> > On 3 June 2012 19:36, Daniel Nicoletti <dantti12@...> wrote:
> >> Ok, it's just that for apt it would mean download only...
> > 
> > Same for yum and zif, so you might have a point. Would anybody else do
> > anything else except download? What about a source distro that needs
> > to download, make but *not* sudo make install?
> 
> For a source distribution, you will still have to install the build
> dependencies (requiring root) in order to complete the package build.
> It could of course still prepare, by downloading distfiles and patches.

How do you want to handle changes between the preparing of the action
and the final application?

A refresh cache call from PackageKit and or from native tools should
tigger a re-preparation of the system upgrade and other transaction,
since it could now include additional packages which would need to be
downloaded or would miss at run time.

How do the update-viewer and the upgrade mechanism work together? Will
all updates be installed at reboot or will the update-viewer still
install updates on request? If not how will queuing several updates in
separate transaction be handled?

Cheers,

Sebastian
(Continue reading)

Permalink | Reply |
headers
Richard Hughes | 5 Jun 2012 15:54
Picon

Re: Adding support for "prepare" in transaction_flags

On 5 June 2012 06:12, Sebastian Heinlein <devel@...> wrote:
> A refresh cache call from PackageKit and or from native tools should
> tigger a re-preparation of the system upgrade and other transaction,
> since it could now include additional packages which would need to be
> downloaded or would miss at run time.

Right, this makes sense. We probably need to remove the
/var/lib/PackageKit/prepared-update file if we do RefreshCache.

> How do the update-viewer and the upgrade mechanism work together? Will
> all updates be installed at reboot or will the update-viewer still
> install updates on request? If not how will queuing several updates in
> separate transaction be handled?

Well, the idea is we let the desktop choose what packages to
auto-install at boot time, and let the user override this in the
session. So for GNOME, we're going to let users live-update in the
session apps that are not open and then force everything else to be
done at startup, unless they drop to the command line.

Richard.
Permalink | Reply |
headers
Sebastian Heinlein | 4 Jun 2012 07:14
Favicon

Re: Adding support for "prepare" in transaction_flags

Am Sonntag, den 03.06.2012, 14:48 +0100 schrieb Richard Hughes: 
> Hi all,
> 
> The new transaction_flags has a new bit that might be set. If the
> PREPARE bit is set, then it's important that the transaction that the
> backend has been asked to do is setup, all the files downloaded, but
> changes actually not made. This is different to simulate, as simulate
> doesn't actually download packages.
> 
> We're intending to use this heavily in GNOME 3.6, so it's kinda
> important to implement in the next few months. I've done zif, and I'll
> do yum on Monday with Nils.

What are the plans for 3.6 exactly? What will be the use case for the
PREPARE flag?

Am Sonntag, den 03.06.2012, 14:48 +0100 schrieb Richard Hughes: 
> Hi all,
> 
> The new transaction_flags has a new bit that might be set. If the
> PREPARE bit is set, then it's important that the transaction that the
> backend has been asked to do is setup, all the files downloaded, but
> changes actually not made. This is different to simulate, as simulate
> doesn't actually download packages.
> 
> We're intending to use this heavily in GNOME 3.6, so it's kinda
> important to implement in the next few months. I've done zif, and I'll
> do yum on Monday with Nils.
(Continue reading)

Permalink | Reply |
headers
Richard Hughes | 4 Jun 2012 09:36
Picon

Re: Adding support for "prepare" in transaction_flags

On 4 June 2012 06:14, Sebastian Heinlein <glatzor@...> wrote:
> What are the plans for 3.6 exactly?

Basically, I'm trying to implement these mockups;
https://live.gnome.org/GnomeOS/Design/Whiteboards/SoftwareUpdates

> What will be the use case for the PREPARE flag?

For gnome-settings-daemon, it can call UpdatePackages(PREPARE) so the
transaction is depsolved and all the required packages and metadata is
downloaded, and then the updates can be applied at early-boot, e.g.
http://freedesktop.org/wiki/Software/systemd/SystemUpdates or upstart
/ initd equivalent.

Richard
Permalink | Reply |

Gmane