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 <[email protected]> >> Michael Straube <[email protected]> >> >> Signed-off-by: Allan McRae <[email protected]> >> --- >> >> 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
