public inbox for cygwin-apps@cygwin.com
 help / color / mirror / Atom feed
From: Ken Brown <kbrown@cornell.edu>
To: cygwin-apps@cygwin.com
Subject: Re: setup: problems with local install
Date: Wed, 07 Mar 2018 21:53:00 -0000	[thread overview]
Message-ID: <19b10cbb-42bc-c82f-be30-57296d3de6c9@cornell.edu> (raw)
In-Reply-To: <a204643c-ddc1-51ca-6b43-fbedce438951@dronecode.org.uk>

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?

Ken

  reply	other threads:[~2018-03-07 21:53 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-05 18:34 Ken Brown
2018-03-06  2:18 ` Ken Brown
2018-03-06 16:38   ` Jon Turney
2018-03-06 15:18 ` Jon Turney
2018-03-06 18:47   ` Jon Turney
2018-03-07 21:53     ` Ken Brown [this message]
2018-03-08 15:59       ` Ken Brown
2018-03-08 21:59         ` Ken Brown
2018-03-12 13:22           ` Ken Brown
2018-03-14 16:07             ` Jon Turney
2018-03-14 19:25               ` Ken Brown
2018-03-15 21:02                 ` Jon Turney
2018-03-06 19:31   ` Ken Brown
2018-03-06 22:13     ` Jon Turney
2018-03-07  7:32     ` Achim Gratz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=19b10cbb-42bc-c82f-be30-57296d3de6c9@cornell.edu \
    --to=kbrown@cornell.edu \
    --cc=cygwin-apps@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).