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.
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?
Still another alternative, and maybe the simplest, is to make sure that
the chooser never shows a version that is not in pkg->versions.
packagemeta::set_action (trusts const trust) almost does this, except
for one useless desired.accessible() call. So that should be fixed, as
well as the setting of the initial action.
Sorry for this stream of consciousness series of posts, but I'll stop
after this one. I think it's possible that restoring the previous
meaning of 'accessible()', at least for local installs, might solve this
problem.
Ken