DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 38D83385840C
Message-ID: <f80cd242-d2ca-49a9-9cfe-4c425a25494c@dronecode.org.uk>
Date: Sun, 21 Jul 2024 17:24:36 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: setup: --prune-install appears to be broken
To: David McFarland <corngood@gmail.com>
References: <87bk3v91n6.fsf@gmail.com>
Content-Language: en-US
Cc: cygwin@cygwin.com
In-Reply-To: <87bk3v91n6.fsf@gmail.com>
Precedence: list
From: Jon Turney via Cygwin <cygwin@cygwin.com>
Reply-To: Jon Turney <jon.turney@dronecode.org.uk>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Errors-To: cygwin-bounces~archive-cygwin=delorie.com@cygwin.com
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie.com@cygwin.com>

On 20/06/2024 14:36, David McFarland via Cygwin wrote:

Sorry for the delay in replying to this.

> 
> If I do a base install to a new root:
> 
>      setup-x86_64.exe --root "$(cygpath -wa .cygtest)" --no-admin \
>          --no-shortcuts --no-replaceonreboot --no-version-check \
>          --prune-install --verbose
> 
> And then run the same install again, I get:
> 
[...]

>      Can't happen.  No packagemeta for base
> 
> The "Can't happen" error results in all following transactions being skipped:
> 
>          // Can't happen - throw an exception?
>          {
>            Log (LOG_PLAIN) << "Can't happen.  No packagemeta for "
>                            << pv.Name() << endLog;
>            return;
>          }

Yeah, that's clearly a bug of some sort.

At the very least, if we're not going to terminate there, it probably 
should be a 'continue' rather than a 'return', so we actually process 
the rest of the transactions.

> This results in setup always showing no pending changes, even if you
> have installed additional packages that should be pruned by
> --prune-install, or if setup.ini has different contents.
> 
> The problem seems to be that we use SOLVER_ERASE jobs to remove all
> non-base installed packages, and they take precedence over keeping the
> pseudo-package 'base' installed.

There's something else going on here I don't understand as there are 
other base or basedep packages in that list of things it wants to erase.

> Making the erase jobs weak seems to solve the problem:
> 
> diff --git a/libsolv.cc b/libsolv.cc
> index 3f083a4..95f21a2 100644
> --- a/libsolv.cc
> +++ b/libsolv.cc
> @@ -850,7 +850,7 @@ SolverSolution::tasksToJobs(SolverTasks &tasks, updateMode update, Queue &job)
>             queue_push2(&job, SOLVER_INSTALL | SOLVER_SOLVABLE_PROVIDES, sv.name_id());
>             break;
>           case SolverTasks::taskUninstall:
> -          queue_push2(&job, SOLVER_ERASE | SOLVER_SOLVABLE, sv.id);
> +          queue_push2(&job, SOLVER_ERASE | SOLVER_WEAK | SOLVER_SOLVABLE, sv.id);
>             break;
>           case SolverTasks::taskReinstall:
>             // we don't know how to ask solver for this, so we just add the erase
> 
> However, I'm not sure if this is a good idea. Perhaps it should only be

Thanks very much for attempting to fix this and providing a patch.

But, yeah, that seems like probably the wrong approach.

(for e.g. seems like that's going make us silently ignore removing X at 
the same time as installing something else which depends on X, when we 
really should to indicate a conflict..)


-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple