[pacman-dev] [PATCH] Add [ignored] to -Qu output for packages in repos that are not Usage = Upgrade

[Allan McRae]

On 4/1/19 7:32 pm, Andrew Gregory wrote:
> On 01/04/19 at 02:21pm, Allan McRae wrote:
>> The behaviour of "pacman -Qu" was very strange...  It would only consider
>> packages from repos with Usage = Search (or All), and ignore those with
>> Usage = Sync, Install or Upgrade.
>>
>> This is because alpm_sync_newversion() used ALPM_DB_USAGE_SEARCH for its
>> filtering. Given this function is documented (at least in the source) to
>> "Check for new version of pkg in sync repos", I would expect that to look at
>> all repos. However, just changing this parameter, would result in a fairly
>> silent change in behaviour of this function.  To counter that, add a parameter
>> to the function that tells it which databases usage levels to consider.
>>
>> Finally, list all available updates in -Qu output, but include [ignored] beside
>> those that will not be updated in a -Su operation due to thier repo Usage
>> value (in addition to those that are Ignored).
>>
>> Fixes FS#59854.
>>
>> With thanks to the following who provided initial patches to print [ignored] on
>> -Qu operations, which highlighted the larger problem:
>> morganamilo <morganamilo at gmail.com>
>> Michael Straube <michael.straube at posteo.de>
>>
>> Signed-off-by: Allan McRae <allan at archlinux.org>
>> ---
>>
>> In comments on earlier patches, there was debate about what the
>> alpm_sync_newversion() is doing.   Although I expect users of this function
>> to likely always pass ALPM_DB_USAGE_ALL, I think changing the function
>> signature is the safest way to handle this change.
>>
>> Comments?
> 
> I was initially on board with this approach, but the more I think
> about it, the more convinced I am that having a function that takes an
> explicit list of db's filter them based on usage is a fundamentally
> bad design.  As I said in the initial discussion, these are low-level
> functions that may be used in different contexts, in which case
> different usage filters would be appropriate.  For example, this patch
> uses newversion with USAGE_ALL because it's being used for purely
> informational purposes.  Manjaro's syncfirst patch, however, uses it
> to actually prepare an upgrade, making USAGE_UPGRADE the correct
> filter.

I was assuming that is a hypothetical!  But the Manjaro patch really
does use alpm_sync_newversion().  They are lucky that no-one probably
used USAGE_SEARCH in their pacman.conf!

> But, requiring the caller to provide a usage everywhere would defeat
> the purpose of making repo usages a back-end feature.  We might as
> well just have the caller do the filtering.  Given that there are only
> a handful of usage levels, the filtered lists could even be cached,
> completely saving us the hassle of iterating over db's that won't get
> used.
> 
> I think the best way to fulfill the original goal of adding repo
> usages would be to move the usage filtering to higher level functions
> that have more narrowly defined purposes and take a handle rather than
> a db list.  This would allow callers that just want to "do the right
> thing" to not have to worry about usages while allowing callers with
> more specific needs to use the low-level functions without having to
> worry about what extra filtering alpm might be doing behind the
> scenes.  It would also result in a cleaner API that doesn't have
> functions ignoring databases they were explicitly told to use.

I have sat and tried to figure out a cleaner API following these ideas
and have failed...   Can you give a brief prototype of what you mean?

Thanks,
Allan