On 3/14/2018 12:07 PM, Jon Turney wrote:
On 12/03/2018 13:22, Ken Brown wrote:
On 3/8/2018 4:59 PM, Ken Brown wrote:
On 3/8/2018 10:59 AM, Ken Brown wrote:
On 3/7/2018 4:52 PM, Ken Brown wrote:
On 3/6/2018 1:47 PM, Jon Turney wrote:
On 06/03/2018 15:18, Jon Turney wrote:
So yeah, I guess putting some complexity back in accessible()
would work, or perhaps the attached? (This doesn't do the right
thing for a few packages, for reasons I'm still looking into...)
To be specific it was doing the wrong thing for those few packages
with no source
/* scan for local copies of package */
-void
+bool
packagemeta::scan (const packageversion &pkg, bool mirror_mode)
{
- /* Already have something */
+ /* empty version */
if (!pkg)
- return;
+ return true;
So, this needs to be 'return false', as the empty version is
always inaccessible, to get the same behaviour as before.
I've found another problem with local installs: If a package needs
upgrading, then the chooser will offer the upgraded version for
install, even if there's no archive available. As a result, the
current version will get uninstalled, and then setup will discover
that it doesn't have the archive to install the new version.
Thanks very much for finding this.
The problem occurs because packagedb::defaultTrust() is called
after ScanDownloadedFiles() has already done its work.
solution.update() and solution.trans2db() are called, and
pkg->desired is set equal to an inaccessible version pv (which has
been previously removed from pkg->versions).
I guess trans2db() should check that pv is in pkg->versions before
acting on an install transaction for pv. And then we also have to
make sure to ignore the erase transaction for the current version
of pkg.
Alternatively, can we just remove an inaccessible packageversion
from the libsolv pool, or at at least just tell libsolv that we
don't want to install it?
Attached is an attempt at that.
I think this is preferable, if it works correctly, as I think avoiding
solutions with these unavailable versions is better than trying to
massage the solution afterwards.
I agree, and it does seem to work correctly. But there's one other case
that it doesn't cover: Suppose there's no archive for the installed
version. Even with your patch, the user can still choose 'Reinstall',
which will fail. The first of the patches from my previous email fixes
this case.
Ken