Re: [pacman-dev] [PATCH] libalpm/sync.c: restrict alpm_sync_newversion by USAGE_UPGRADE
On 07/24/2018 09:23 PM, Morgan Adamiec wrote: > On Tue, 24 Jul 2018 at 20:40, Andrew Gregory > wrote: >> Based on how it's used, I'd say it should be SEARCH; it's being used >> as a filter for -Q and no upgrade transaction is being performed, or >> even prepared. >> >> Really, though, I'd say this is a great example as to why usages >> should have been implemented in the front-end or limited to only the >> highest-level library functions. Usage is contextual, how is libalpm >> supposed to know how such a basic function is being used? pacman may >> only use it as a filter for -Q, but some other front-end could use it >> to actually prepare an upgrade. > > The thing is pacman with not let you use -s with -u: error: invalid > option: '--search' and '--upgrade' may not be used together. By that > logic you could argue it is not a search at all. It has nothing to do with "upgrades", -S means different things depending on whether you just give it package names, a bunch of inferred package names via -u, or whatever. -Us doesn't work either. Nor does -Ssw. Likewise this low-level function I guess is not called just by pacman -Su ... > Front ends aside the function is called alpm_sync_newversion, it makes > no mention to searching. It is a function to find packages from sync repositories (in contrast to the "local" repository) that have new versions. I think it's obvious this function does not handle the actual syncing... Anyway. Seems to me the name is a reference to the local/remote nature of the repo, not its Usage field. > Slightly off topic of the original patch. Playing around more I've > come to find that Upgrade implies Install. Is that an oversight or is > it intended? It implies this where? Shouldn't anything using it be checking/specifying both bitmasks? -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [pacman-dev] [PATCH] libalpm/sync.c: restrict alpm_sync_newversion by USAGE_UPGRADE
On 07/24/2018 02:48 PM, Dave Reisner wrote: > On Tue, Jul 24, 2018 at 05:53:00PM +0100, morganamilo wrote: >> Commit 106d0fc54 Added the usage option for databases and >> alpm_sync_newversion was restricted by USAGE_SEARCH instead of >> USAGE_UPGRADE. > > I don't recall exactly what my thinking was when I wrote this patch, but > looking at 'pacman -Qu' output right now, I think I actually I like > seeing potential upgrades, not just "actual" upgrades. > > Anyone else have an opinion? I don't really see the utility... a search-only database will not show the upgrades in pacman -Su (even ignored packages get shown, just as a warning instead of an active transaction member). pacman -Qu should therefore (IMHO) only show those Sync packages (with [ignored] in cases, yes). When people hear about -Qu, they generally hear about it as "oh, the thing which is like -Su except it doesn't actually do the thing". Admittedly the actual thing which doesn't actually do the thing would be pacman -Sup --print-format '%r/%n %v' But then we're faced with the classic problem "print-format? no such thing, we don't support that and you should use expac, HAHAHAHA, oh wait print-format is actually useful here (surprise!)" So actually I guess in theory it's completely different, but now I'm not sure what I would specifically use this behavior for. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [pacman-dev] [PATCH] libalpm/sync.c: restrict alpm_sync_newversion by USAGE_UPGRADE
On Wed, 25 Jul 2018 at 02:28, Andrew Gregory wrote: > It makes no mention of upgrading either It is called alpm_sync_*newversion* >How is that different from just putting that repo below the one you want it to use normally? pacman -S pkg should return an error. These packages are not in any other of my repos, so there is nothing to move it under really. But bedsides that It would just make more sense for Upgrade to not imply install. Or at least document that it does.
Re: [pacman-dev] [PATCH] libalpm/sync.c: restrict alpm_sync_newversion by USAGE_UPGRADE
On 07/25/18 at 02:23am, Morgan Adamiec wrote: > On Tue, 24 Jul 2018 at 20:40, Andrew Gregory > wrote: > > Based on how it's used, I'd say it should be SEARCH; it's being used > > as a filter for -Q and no upgrade transaction is being performed, or > > even prepared. > > > > Really, though, I'd say this is a great example as to why usages > > should have been implemented in the front-end or limited to only the > > highest-level library functions. Usage is contextual, how is libalpm > > supposed to know how such a basic function is being used? pacman may > > only use it as a filter for -Q, but some other front-end could use it > > to actually prepare an upgrade. > > The thing is pacman with not let you use -s with -u: error: invalid > option: '--search' and '--upgrade' may not be used together. By that > logic you could argue it is not a search at all. > Front ends aside the function is called alpm_sync_newversion, it makes > no mention to searching. It makes no mention of upgrading either. > Slightly off topic of the original patch. Playing around more I've > come to find that Upgrade implies Install. Is that an oversight or is > it intended? > As for use case I would like tp pacman -S db/pkg explicitly and have > them upgrade but never touch the repo during a normal pacman -S pkg. How is that different from just putting that repo below the one you want it to use normally?
Re: [pacman-dev] [PATCH] libalpm/sync.c: restrict alpm_sync_newversion by USAGE_UPGRADE
On Tue, 24 Jul 2018 at 20:40, Andrew Gregory wrote: > Based on how it's used, I'd say it should be SEARCH; it's being used > as a filter for -Q and no upgrade transaction is being performed, or > even prepared. > > Really, though, I'd say this is a great example as to why usages > should have been implemented in the front-end or limited to only the > highest-level library functions. Usage is contextual, how is libalpm > supposed to know how such a basic function is being used? pacman may > only use it as a filter for -Q, but some other front-end could use it > to actually prepare an upgrade. The thing is pacman with not let you use -s with -u: error: invalid option: '--search' and '--upgrade' may not be used together. By that logic you could argue it is not a search at all. Front ends aside the function is called alpm_sync_newversion, it makes no mention to searching. Slightly off topic of the original patch. Playing around more I've come to find that Upgrade implies Install. Is that an oversight or is it intended? As for use case I would like tp pacman -S db/pkg explicitly and have them upgrade but never touch the repo during a normal pacman -S pkg.
Re: [pacman-dev] [PATCH] libalpm/sync.c: restrict alpm_sync_newversion by USAGE_UPGRADE
On 07/24/18 at 02:48pm, Dave Reisner wrote: > On Tue, Jul 24, 2018 at 05:53:00PM +0100, morganamilo wrote: > > Commit 106d0fc54 Added the usage option for databases and > > alpm_sync_newversion was restricted by USAGE_SEARCH instead of > > USAGE_UPGRADE. > > I don't recall exactly what my thinking was when I wrote this patch, but > looking at 'pacman -Qu' output right now, I think I actually I like > seeing potential upgrades, not just "actual" upgrades. > > Anyone else have an opinion? Based on how it's used, I'd say it should be SEARCH; it's being used as a filter for -Q and no upgrade transaction is being performed, or even prepared. Really, though, I'd say this is a great example as to why usages should have been implemented in the front-end or limited to only the highest-level library functions. Usage is contextual, how is libalpm supposed to know how such a basic function is being used? pacman may only use it as a filter for -Q, but some other front-end could use it to actually prepare an upgrade.
Re: [pacman-dev] [PATCH] libalpm/sync.c: restrict alpm_sync_newversion by USAGE_UPGRADE
On Tue, Jul 24, 2018 at 05:53:00PM +0100, morganamilo wrote:
> Commit 106d0fc54 Added the usage option for databases and
> alpm_sync_newversion was restricted by USAGE_SEARCH instead of
> USAGE_UPGRADE.
I don't recall exactly what my thinking was when I wrote this patch, but
looking at 'pacman -Qu' output right now, I think I actually I like
seeing potential upgrades, not just "actual" upgrades.
Anyone else have an opinion?
> USAGE_UPGRADE should be used instead. This means packages only show up
> in commands such as `pacman -Qu` if the database Has the Upgrade option.
>
> Signed-off-by: morganamilo
>
> diff --git a/lib/libalpm/sync.c b/lib/libalpm/sync.c
> index 696a5131..23b0ccfa 100644
> --- a/lib/libalpm/sync.c
> +++ b/lib/libalpm/sync.c
> @@ -61,7 +61,7 @@ alpm_pkg_t SYMEXPORT *alpm_sync_newversion(alpm_pkg_t *pkg,
> alpm_list_t *dbs_syn
>
> for(i = dbs_sync; !spkg && i; i = i->next) {
> alpm_db_t *db = i->data;
> - if(!(db->usage & ALPM_DB_USAGE_SEARCH)) {
> + if(!(db->usage & ALPM_DB_USAGE_UPGRADE)) {
> continue;
> }
>
> --
> 2.18.0
[pacman-dev] [PATCH] libalpm/sync.c: restrict alpm_sync_newversion by USAGE_UPGRADE
Commit 106d0fc54 Added the usage option for databases and
alpm_sync_newversion was restricted by USAGE_SEARCH instead of
USAGE_UPGRADE.
USAGE_UPGRADE should be used instead. This means packages only show up
in commands such as `pacman -Qu` if the database Has the Upgrade option.
Signed-off-by: morganamilo
diff --git a/lib/libalpm/sync.c b/lib/libalpm/sync.c
index 696a5131..23b0ccfa 100644
--- a/lib/libalpm/sync.c
+++ b/lib/libalpm/sync.c
@@ -61,7 +61,7 @@ alpm_pkg_t SYMEXPORT *alpm_sync_newversion(alpm_pkg_t *pkg,
alpm_list_t *dbs_syn
for(i = dbs_sync; !spkg && i; i = i->next) {
alpm_db_t *db = i->data;
- if(!(db->usage & ALPM_DB_USAGE_SEARCH)) {
+ if(!(db->usage & ALPM_DB_USAGE_UPGRADE)) {
continue;
}
--
2.18.0
