Allow to specify a custom repo for the local cache #119

terencode · 2020-05-08T14:07:53Z

It seems this tool only allow downgrading packages from the default local pacman repo.
However, if the user created a custom repo for say all the AUR packages, downgrade will not find the different package versions.

I'd like an option like downgrade --repo <repo-name>

EDIT: It seems you can use --pacman-conf but it will only work if you have the repo configured in a separate pacman.d file, and it's not very convenient to use.

The text was updated successfully, but these errors were encountered:

pbrisbin · 2020-05-08T14:16:18Z

Can you try PACMAN_CACHE?

% PACMAN_CACHE='/var/cache/pacman/pkg/ /var/cache/aur/pkg/' downgrade foo

terencode · 2020-05-08T14:21:24Z

Yup, that works, sorry.

terencode · 2020-05-08T14:22:01Z

Would it be suitable to make downgrade use all cache location by default?

pbrisbin · 2020-05-08T14:23:15Z

I think that makes sense! Feel free to report that as a separate feature request (with example pacman.conf and desired behavior, please). Or, ideally, a PR 😄

atreyasha · 2020-05-08T18:01:29Z

If we push through with this as a PR, it would be good if we could then pass PACMAN_CACHE and PACMAN_LOG as command-line options, just to ensure that all environmental variables have consistent command-line counterparts. This would be consistent with changes made in #96.

Also, if we want to expand to searching all possible cache locations, we could also consider adding the maximum depth in the find command for cache search to be an adjustable command-line option, as package manager wrappers like yay use a nested (non-open) structure in the cache directories for storing AUR tarballs. In that case, we would need a maxdepth of at least 2 to find the packages.

WDYT? I don't mind personally developing this in the next iteration(s) if it is of interest. Not sure what priority this would take with respect to our other two open issues #83 and #118.

pbrisbin · 2020-05-08T18:54:21Z

If we push through with this as a PR, it would be good if we could then pass PACMAN_CACHE and PACMAN_LOG as command-line options, just to ensure that all environmental variables have consistent command-line counterparts.

If @terencode wishes to contribute, I'm comfortable with them just solving their immedate problem and us handling that aspect as a separate issue. In fact, it seems like a separate issue anyway. These should have command line flags (or not) regardless of us working on better defaults (this Issue).

Also, if we want to expand to searching all possible cache locations, we could also consider adding the maximum depth in the find command for cache search to be an adjustable command-line option

Is it possible just to increase or remove the current -maxdepth? I don't even remember why it's there; is the default cache directory deeply nested with non-package files, such than a naive find would be super slow?

I don't mind personally developing this in the next iteration(s) if it is of interest

Up to @terencode if they'd like to contribute. If not, go for it.

Not sure what priority this would take with respect to our other two open issues

I think I'm m going to configure Projects for this repo, now that we're getting more maintainers collaborating. We can slot things into a Backlog column to indicate priority and use assignment and an In-Progress column to indicate ongoing work. I don't have an opinion on priority between our current Issues, only that we have some clear approach to indicating it.

atreyasha · 2020-05-08T19:27:48Z

Is it possible just to increase or remove the current -maxdepth? I don't even remember why it's there; is the default cache directory deeply nested with non-package files, such than a naive find would be super slow?

If we specify the cache directory as /var/cache/pacman/pkg, maxdepth has little to no effect since all tarballs are laid out in that directory and are not nested deeper. So maxdepth is probably unnecessary there.

For other cases, it might be necessary, especially if we want to search for cached packages where there are other large directories present. We can address this in a new issue.

terencode · 2020-05-10T13:20:27Z

@atreyasha feel free to contribute if you are motivated ;).

atreyasha · 2020-05-17T14:01:38Z

Would it be suitable to make downgrade use all cache location by default?

With #123, it should be possible to search more cache locations with varying file structures. For example:

$ downgrade --pacman-cache '/var/cache/' --maxdepth 3 foo bar

You can vary the --maxdepth parameter based on how deep the tarballs are located relative to the supplied --pacman-cache.

terencode · 2020-05-17T14:03:34Z

Very nice, thank you!

terencode · 2020-05-17T14:52:00Z

Ok I tested it and while it works well, I think it could benefit from a couple of improvements:

Show current version of the packages you wish to downgrade
Print for each package downgrade the database it came from (right now it only shows local but it would be better if instead we had local/core and local/community etc.)
While it seems it picks up the Cachedir from /etc/pacman.conf, I still have to use pacman-cache for it to find my packages
You have to be careful not to forget the '/' at the end of the path otherwise it does not work
Can maxdepth default to 2 when --pacman-cache is used?

atreyasha · 2020-05-17T15:13:29Z

Show current version of the packages you wish to downgrade

Hmm, so if the package you wish to downgrade is already installed, the current version is shown in the generated table with a + symbol on the left-hand side. The - symbol indicates that version was previously installled. No symbol indicates it was never installed.

Print for each package downgrade the database it came from (right now it only shows local but it would be better if instead we had local/core and local/community etc.)

Would be good to get views from @pbrisbin here. AFAIK, this could be possible by just querying via pacman before the table printing. Although this could be problematic if AUR packages are present, meaning we would need to have some wrapper to verify that a package is indeed an AUR package -> which could entail adding more dependencies.

While it seems it picks up the Cachedir from /etc/pacman.conf, I still have to use pacman-cache for it to find my packages

I just tested this and it is possible to have the following lines in /etc/pacman.conf:

CacheDir    = /var/cache/pacman/pkg
CacheDir    = /path/to/another/cache/dir

downgrade should be able to read and search both. I tested this and it works on my local system. Although you might need to play with --maxdepth if your other caches are structured differently in terms of depth.

You have to be careful not to forget the '/' at the end of the path otherwise it does not work

In my case, with or without the trailing slash did not affect the search. Could you provide the command that did not work for you?

Can maxdepth default to 2 when --pacman-cache is used?

Once again would be good to get views from @pbrisbin here. Maybe this issue of diverging defaults could be settled by having a downgrade.conf configuration file?

@terencode if you require this as a default right away, maybe alias downgrade='downgrade --maxdepth 2' could help for now?

atreyasha · 2020-05-17T15:15:04Z

Re-opening this issue as there could be some things to discuss still.

terencode · 2020-05-17T15:26:08Z

Hmm, so if the package you wish to downgrade is already installed, the current version is shown in the generated table with a + symbol on the left-hand side. The - symbol indicates that version was previously installled.

Ok that works, I would have just prefered masking it and having it on top so it's easier to compare versions.

I just tested this and it is possible to have the following lines in /etc/pacman.conf:

Indeed, but for me it does not pick up the second Cachedir probably because it's on a separate file in the /etc/pacman.d dir and I then include it to pacman.conf with Include =/etc/pacman.d/<db-name>

In my case, with or without the trailing slash did not affect the search. Could you provide the command that did not work for you?

downgrade --pacman-cache ~/.cache/pacman --maxdepth 2 <pkgname>
says Unable to downgrade <pkgname>
but downgrade --pacman-cache ~/.cache/pacman/ --maxdepth 2 <pkgname>
works.

Once again would be good to get views from @pbrisbin here. Maybe this issue of diverging defaults could be settled by having a downgrade.conf configuration file?

A custom configuration file would be welcome indeed. I would think most user with a local repo would put its cache next to the pacman one but I might be wrong.
Here, I have ~/.cache/pacman/aur and ~/.cache/pacman/pkg.

@terencode if you require this as a default right away, maybe alias downgrade='downgrade --maxdepth 2' could help for now?

Yes that's a good enough workaround for when the Cachedir issue is fixed :)

atreyasha · 2020-05-17T15:34:48Z

I just tested this and it is possible to have the following lines in /etc/pacman.conf:

Indeed, but for me it does not pick up the second Cachedir probably because it's on a separate file in the /etc/pacman.d dir and I then include it to pacman.conf with Include =/etc/pacman.d/<db-name>

Ah I see. Yes, the current line to read from /etc/pacman.conf is as follows:

https://github.com/pbrisbin/downgrade/blob/master/downgrade#L37

read_pacman_conf() { sed '/^#\?'"$1"' *= *\(.*\)$/!d; s//\1/' "$PACMAN_CONF"; }

In downgrade, we only supply CacheDir and LogFile as $1, so only those would be read and not any of the include's. This could be a good addition to deal with the include's.

In my case, with or without the trailing slash did not affect the search. Could you provide the command that did not work for you?

downgrade --pacman-cache ~/.cache/pacman --maxdepth 2 <pkgname>
says Unable to downgrade <pkgname>
but downgrade --pacman-cache ~/.cache/pacman/ --maxdepth 2 <pkgname>
works.

Hmm, I am able to get search results for downgrade --pacman-cache ~/.cache/pacman --maxdepth 2 <pkgname>.

I know sometimes find is not too happy with non-absolute paths such as with ~. Are you able to get complete results with both of these?

$ downgrade --pacman-cache "/home/<user>/.cache/pacman" --maxdepth 2 <pkgname>

$ downgrade --pacman-cache "/home/<user>/.cache/pacman/" --maxdepth 2 <pkgname>

terencode · 2020-05-17T15:39:06Z

I know sometimes find is not too happy with non-absolute paths such as with ~. Are you able to get complete results with both of these?

Same behaviour as before unfortunately.

atreyasha · 2020-05-17T16:04:38Z

Just to summarize some main discussion points in this issue :

Modify local and remote to something more specific like local (core), local (community) etc. Could be problematic when dealing with AUR packages, which require a wrapper to verify if they are indeed AUR packages.
Look into include's in /etc/pacman.conf and how we pick up other cache directories.
Consider making a downgrade-specific configuration file to set defaults.
Check whether downgrade --pacman-cache ~/.cache/pacman --maxdepth 2 <pkgname> or similar command without trailing slash on path fails for other users. @pbrisbin maybe you could test this on your system?
Maybe we add a --debug command-line option to downgrade which would be much more verbose with variable and array-printing. We could request users to run problematic commands with --debug to identify locations of bugs.

atreyasha · 2020-05-18T12:51:08Z

@terencode for point 4, could you paste the output of bash -x downgrade --pacman-cache ~/.cache/pacman --maxdepth 2 <pkgname>?

pbrisbin · 2020-05-18T13:03:59Z

Sorry for my terse mobile reply, but it wanted to leave some thoughts until I can get back to my computer.

1- SGTM, though if the option is there to pass arbitrary cache directories, don't we need to show that (and deal with long lines)? We can't know the cache name all the time.

2- seems not worth the complexity. If someone were very serious about this feature, I'd encourage them to contribute a stand alone exe to pacman that reuses its own config code to resolve includes and print values (this could very well exist), then we could use that here

3- since every option has an env var, some export lines in bashrc is meant to be the config file. If one really wanted, they could put exports into a specific file and make a wrapper to source it and call downgrade to achieve the same.

4- I can investigate this week

5- I love me some good --debug :)

terencode · 2020-05-18T13:06:25Z

@atreyasha here you go:

+ . gettext.sh
++ test 'X\t' = 'X\t'
++ echo=echo
++ test -z ''
++ case "$0" in
+ : ''
+ : ''
+ : ''
+ : ''
+ '[' '' = 1 ']'
+ '[' '' = 1 ']'
+ '[' '' = 1 ']'
+ : pacman
+ : /etc/pacman.conf
++ uname -m
+ : x86_64
+ : https://archive.archlinux.org
+ : 1
+ : 1
+ : 0
+ : 1
+ declare -a terms
+ declare -a to_ignore
+ declare -a to_install
+ declare -a pacman_args
+ declare -a installed
+ declare current
+ (( !LIB ))
+ set -e
++ dirname downgrade
+ locale=./../share/locale
+ [[ -d ./../share/locale ]]
+ TEXTDOMAINDIR=/usr/share/locale
+ export TEXTDOMAIN=downgrade TEXTDOMAINDIR
+ TEXTDOMAIN=downgrade
+ cli --pacman-cache /home/terence/.cache/pacman --maxdepth 2 gnome-shell-extension-gsconnect-git
+ parse_options --pacman-cache /home/terence/.cache/pacman --maxdepth 2 gnome-shell-extension-gsconnect-git
+ [[ -n --pacman-cache ]]
+ case "$1" in
+ [[ -n /home/terence/.cache/pacman ]]
+ shift
+ PACMAN_CACHE=/home/terence/.cache/pacman
+ shift
+ [[ -n --maxdepth ]]
+ case "$1" in
+ [[ -n 2 ]]
+ shift
+ DOWNGRADE_MAXDEPTH=2
+ shift
+ [[ -n gnome-shell-extension-gsconnect-git ]]
+ case "$1" in
+ terms+=("$1")
+ shift
+ [[ -n '' ]]
+ (( !1 ))
+ (( DOWNGRADE_NOSUDO ))
+ type -p sudo
+ main gnome-shell-extension-gsconnect-git
+ local term candidates choice pkg exit_code=0
+ (( 1 ))
+ for term in "$@"
+ process_term gnome-shell-extension-gsconnect-git
+ local term=gnome-shell-extension-gsconnect-git name operator version candidates choice
+ read -r name operator version
++ sed -r 's/(.*[^<>=~])(<=|>=|<|>|=|=~)([^<>=~].*)/\1 \2 \3/g'
+ installed=($(previously_installed "$name"))
++ previously_installed gnome-shell-extension-gsconnect-git
+++ read_pacman_conf LogFile
+++ sed '/^#\?LogFile *= *\(.*\)$/!d; s//\1/' /etc/pacman.conf
++ : /var/log/pacman.log
++ : /var/log/pacman.log
++ sed '
    /.*\(installed\|upgraded\) \(gnome-shell-extension-gsconnect-git\) (\(.* -> \)\?\([^)]*\))/!d
    s//\2-\4/
  ' /var/log/pacman.log
++ currently_installed gnome-shell-extension-gsconnect-git
++ LC_ALL=C.UTF8
++ pacman -Qi gnome-shell-extension-gsconnect-git
++ awk -F ' : ' '
    /^Name / { name=$2 };
    /^Version / { version=$2 };
    END { if (name != "") printf("%s-%s\n", name, version) }
  '
+ current=gnome-shell-extension-gsconnect-git-38.r8.gaa2753fb-1
+ candidates=($(search_packages "$name" | filter_packages "$name" "$operator" "$version" | sort_packages))
++ search_packages gnome-shell-extension-gsconnect-git
++ local name=gnome-shell-extension-gsconnect-git pkgfile_re index
++ pkgfile_re='gnome-shell-extension-gsconnect-git-[^-]+-[0-9.]+-(any|x86_64)\.pkg\.tar\.(gz|xz|zst)'
++ filter_packages gnome-shell-extension-gsconnect-git '' ''
++ sort_packages
++ index=https://archive.archlinux.org/packages/g/gnome-shell-extension-gsconnect-git/
++ (( DOWNGRADE_FROM_ALA ))
++ local name=gnome-shell-extension-gsconnect-git operator= version= pkg
++ read -r pkg
++ grep -Fv testing/
++ curl --fail --silent https://archive.archlinux.org/packages/g/gnome-shell-extension-gsconnect-git/
++ sed -E '
      /.* href="(gnome-shell-extension-gsconnect-git-[^-]+-[0-9.]+-(any|x86_64)\.pkg\.tar\.(gz|xz|zst))".*/!d;
      s||https://archive.archlinux.org/packages/g/gnome-shell-extension-gsconnect-git/\1|g; s|\+| |g; s|%|\\x|g'
++ xargs -0 printf %b
++ awk 'BEGIN { FS="/"; OFS="|" } { print $NF, $0 }'
++ pacsort -f -t '|' -k 1
++ cut -d '|' -f 2-
++ (( DOWNGRADE_FROM_CACHE ))
++ : /home/terence/.cache/pacman
++ : /home/terence/.cache/pacman
++ find /home/terence/.cache/pacman -maxdepth 2 -regextype posix-extended -regex '.*/gnome-shell-extension-gsconnect-git-[^-]+-[0-9.]+-(any|x86_64)\.pkg\.tar\.(gz|xz|zst)'
+ (( 0 == 1 ))
+ present_packages gnome-shell-extension-gsconnect-git
+ local i=1
+ local pkgname=gnome-shell-extension-gsconnect-git
+ shift
+ (( 0 ))
+ return 1
+ [[ -n '' ]]
+ eval_gettext 'Unable to downgrade $name'
+ gettext 'Unable to downgrade $name'
++ envsubst --variables 'Unable to downgrade $name'
+ export PATH name
+ envsubst 'Unable to downgrade $name'
Unable to downgrade gnome-shell-extension-gsconnect-git+ echo

+ return 1
+ exit_code=1
+ return 1

atreyasha · 2020-05-18T14:25:24Z

I tried to replicate your cache directory structure using a locally built tarball of gnome-shell-extension-gsconnect-git, but was unable to reproduce the error.

++ find /home/terence/.cache/pacman -maxdepth 2 -regextype posix-extended -regex '.*/gnome-shell-extension-gsconnect-git-[^-]+-[0-9.]+-(any|x86_64)\.pkg\.tar\.(gz|xz|zst)'
+ (( 0 == 1 ))

This part of the error message shows that find was executed and no packages matching the regex were found. This is really the bottleneck here.

What are the outputs of the following commands?

ls -al /home/terence/.cache/pacman

find /home/terence/.cache/pacman -maxdepth 2 -regextype posix-extended -regex '.*/gnome-shell-extension-gsconnect-git-[^-]+-[0-9.]+-(any|x86_64)\.pkg\.tar\.(gz|xz|zst)'

find /home/terence/.cache/pacman/ -maxdepth 2 -regextype posix-extended -regex '.*/gnome-shell-extension-gsconnect-git-[^-]+-[0-9.]+-(any|x86_64)\.pkg\.tar\.(gz|xz|zst)'

find /home/terence/.cache/pacman -maxdepth 4 -regextype posix-extended -regex '.*/gnome-shell-extension-gsconnect-git-[^-]+-[0-9.]+-(any|x86_64)\.pkg\.tar\.(gz|xz|zst)'

find /home/terence/.cache/pacman/ -maxdepth 4 -regextype posix-extended -regex '.*/gnome-shell-extension-gsconnect-git-[^-]+-[0-9.]+-(any|x86_64)\.pkg\.tar\.(gz|xz|zst)'

find /home/terence/.cache/pacman -maxdepth 2 -regextype posix-extended -regex '.*gnome-shell-extension-gsconnect-git-[^-]+-[0-9.]+-(any|x86_64)\.pkg\.tar\.(gz|xz|zst)'

find /home/terence/.cache/pacman/ -maxdepth 2 -regextype posix-extended -regex '.*gnome-shell-extension-gsconnect-git-[^-]+-[0-9.]+-(any|x86_64)\.pkg\.tar\.(gz|xz|zst)'

atreyasha · 2020-05-18T14:33:26Z

If this does not fix it, I won't bother you with more of these tests :) We can just wait till @pbrisbin tries to reproduce it.

terencode · 2020-05-18T14:56:50Z

ls -al /home/terence/.cache/pacman

lrwxrwxrwx 1 terence terence 21 17 juil. 2019 /home/terence/.cache/pacman -> /mnt/WDC/Cache/pacman

find /home/terence/.cache/pacman -maxdepth 2 -regextype posix-extended -regex '.*/gnome-shell-extension-gsconnect-git-[^-]+-[0-9.]+-(any|x86_64).pkg.tar.(gz|xz|zst)'

nothing

find /home/terence/.cache/pacman/ -maxdepth 2 -regextype posix-extended -regex '.*/gnome-shell-extension-gsconnect-git-[^-]+-[0-9.]+-(any|x86_64).pkg.tar.(gz|xz|zst)'

/home/terence/.cache/pacman/pkg/gnome-shell-extension-gsconnect-git-21.rc1.r4.gc480564e-1-any.pkg.tar.xz
/home/terence/.cache/pacman/pkg/gnome-shell-extension-gsconnect-git-21.rc1.r6.g1f9ee60f-1-any.pkg.tar.xz
/home/terence/.cache/pacman/aur/gnome-shell-extension-gsconnect-git-38.r8.gaa2753fb-1-any.pkg.tar.zst
/home/terence/.cache/pacman/aur/gnome-shell-extension-gsconnect-git-38.r5.gce2cf171-1-any.pkg.tar.zst

find /home/terence/.cache/pacman -maxdepth 4 -regextype posix-extended -regex '.*/gnome-shell-extension-gsconnect-git-[^-]+-[0-9.]+-(any|x86_64).pkg.tar.(gz|xz|zst)'

nothing

find /home/terence/.cache/pacman/ -maxdepth 4 -regextype posix-extended -regex '.*/gnome-shell-extension-gsconnect-git-[^-]+-[0-9.]+-(any|x86_64).pkg.tar.(gz|xz|zst)'

/home/terence/.cache/pacman/pkg/gnome-shell-extension-gsconnect-git-21.rc1.r4.gc480564e-1-any.pkg.tar.xz
/home/terence/.cache/pacman/pkg/gnome-shell-extension-gsconnect-git-21.rc1.r6.g1f9ee60f-1-any.pkg.tar.xz
/home/terence/.cache/pacman/aur/gnome-shell-extension-gsconnect-git-38.r8.gaa2753fb-1-any.pkg.tar.zst
/home/terence/.cache/pacman/aur/gnome-shell-extension-gsconnect-git-38.r5.gce2cf171-1-any.pkg.tar.zst

find /home/terence/.cache/pacman -maxdepth 2 -regextype posix-extended -regex '.*gnome-shell-extension-gsconnect-git-[^-]+-[0-9.]+-(any|x86_64).pkg.tar.(gz|xz|zst)'

nothing

find /home/terence/.cache/pacman/ -maxdepth 2 -regextype posix-extended -regex '.*gnome-shell-extension-gsconnect-git-[^-]+-[0-9.]+-(any|x86_64).pkg.tar.(gz|xz|zst)'


/home/terence/.cache/pacman/pkg/gnome-shell-extension-gsconnect-git-21.rc1.r4.gc480564e-1-any.pkg.tar.xz
/home/terence/.cache/pacman/pkg/gnome-shell-extension-gsconnect-git-21.rc1.r6.g1f9ee60f-1-any.pkg.tar.xz
/home/terence/.cache/pacman/aur/gnome-shell-extension-gsconnect-git-38.r8.gaa2753fb-1-any.pkg.tar.zst
/home/terence/.cache/pacman/aur/gnome-shell-extension-gsconnect-git-38.r5.gce2cf171-1-any.pkg.tar.zst

atreyasha · 2020-05-18T15:16:53Z

lrwxrwxrwx 1 terence terence 21 17 juil. 2019 /home/terence/.cache/pacman -> /mnt/WDC/Cache/pacman

I can reproduce the error now, it has to do with the symlink to another directory. Seems like without the deliberate trailing slash at the end, find does not search deeper into pacman and just assumes it is a file. With the trailing slash, find probes into the contents.

This is a good find. One rudimentary fix is to force post-pend a slash on all pacman caches, since extra slashes will not change the semantics. Alternatively, there could also be an option within find to force searching symlinks.

We can add this as a fix in the upcoming release(s). Thanks @terencode!

terencode · 2020-05-18T15:25:17Z

Thanks for your perspicacity @atreyasha ;)

atreyasha · 2020-05-18T15:45:48Z

Thanks for your perspicacity @atreyasha ;)

Happy to be of use while stuck at home :D

@pbrisbin:

To overcome this issue of following symlinks, we can prepend options -H or -L, for example find -H ... or find -L .... Tested these and both worked. Maybe we could choose which option sounds better (and safer) for resolving such an issue. -H sounds like a safer and more conservative option to me.

Also, can I label this issue as a bug?

       -L     Follow symbolic links.  When  find  examines  or  prints  information
              about  files, the information used shall be taken from the properties
              of the file to which the link points, not from the link  itself  (un‐
              less  it  is  a broken symbolic link or find is unable to examine the
              file to which the link points).  Use of this option implies  -noleaf.
              If  you later use the -P option, -noleaf will still be in effect.  If
              -L is in effect and find discovers a symbolic link to a  subdirectory
              during  its  search, the subdirectory pointed to by the symbolic link
              will be searched.

              When the -L option is in effect,  the  -type  predicate  will  always
              match  against  the  type  of the file that a symbolic link points to
              rather than the link itself (unless the  symbolic  link  is  broken).
              Actions  that can cause symbolic links to become broken while find is
              executing (for example -delete) can give rise to confusing behaviour.
              Using  -L  causes  the -lname and -ilname predicates always to return
              false.

       -H     Do not follow symbolic links, except  while  processing  the  command
              line  arguments.   When  find  examines  or  prints information about
              files, the information used shall be taken from the properties of the
              symbolic link itself.  The only exception to this behaviour is when a
              file specified on the command line is a symbolic link, and  the  link
              can  be  resolved.  For that situation, the information used is taken
              from whatever the link points to (that is,  the  link  is  followed).
              The  information  about  the link itself is used as a fallback if the
              file pointed to by the symbolic link cannot be examined.  If -H is in
              effect  and  one of the paths specified on the command line is a sym‐
              bolic link to a directory, the contents of that directory will be ex‐
              amined (though of course -maxdepth 0 would prevent this).

pbrisbin · 2020-05-18T16:06:52Z

I'm not against post-pending a / all the time, or adding -L or -H all the time. However, what if we replaced DOWNGRADE_MAXDEPTH with DOWNGRADE_FIND_OPTIONS (akin to PACMAN_OPTIONS)? Then the user could decide the appropriate -maxdepth and -L or -H settings for their use-case. By default, I think we would pass nothing special, which means we'd be removing -maxdepth for default usage.

atreyasha · 2020-05-18T16:31:15Z

I'm not against post-pending a / all the time, or adding -L or -H all the time. However, what if we replaced DOWNGRADE_MAXDEPTH with DOWNGRADE_FIND_OPTIONS (akin to PACMAN_OPTIONS)? Then the user could decide the appropriate -maxdepth and -L or -H settings for their use-case. By default, I think we would pass nothing special, which means we'd be removing -maxdepth for default usage.

Possible, but we might encounter some issues. Below is the usage syntax of find:

SYNOPSIS
       find  [-H]  [-L]  [-P] [-D debugopts] [-Olevel] [starting-point...] [expres‐
       sion]

This means we would actively have to split whichever options the user provides into the relevant categories and place them either before or after the [starting-point...]. For example, --maxdepth N has to be after the starting point and -H has to be before the starting point. So maybe this might add more work for downgrade.

pbrisbin · 2020-05-18T17:18:10Z

Oh that's too bad. I agree it's not a useful idea, given that.

atreyasha · 2020-08-23T17:07:16Z

Main remaining points of this issue have been transferred to #133. Closing this issue.

terencode closed this as completed May 8, 2020

atreyasha mentioned this issue May 8, 2020

Non-interactive downgrading with version-filtering #118

Open

atreyasha mentioned this issue May 8, 2020

Creating --pacman-log, --pacman-cache and --maxdepth command-line arguments #120

Closed

atreyasha reopened this May 17, 2020

atreyasha added the triage Requires triage to ascertain relevance and actions label May 17, 2020

atreyasha mentioned this issue May 21, 2020

Adding -L flag to find to search explicitly provided symlinks #125

Merged

atreyasha added priority: 2 enhancement and removed triage Requires triage to ascertain relevance and actions labels May 21, 2020

atreyasha self-assigned this May 21, 2020

atreyasha added this to To do in Backlog via automation May 21, 2020

atreyasha linked a pull request Aug 23, 2020 that will close this issue

Adding -L flag to find to search explicitly provided symlinks #125

Merged

atreyasha added modify-feature Modify or fix an existing feature and removed priority: 2 enhancement labels Aug 23, 2020

atreyasha mentioned this issue Aug 23, 2020

Package DB printing, include-path searches, downgrade configuration files and debugging #133

Closed

atreyasha closed this as completed Aug 23, 2020

Backlog automation moved this from To do to Done Aug 23, 2020

atreyasha linked a pull request Oct 22, 2020 that will close this issue

Pacman cache accumulation #141

Merged

6 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Allow to specify a custom repo for the local cache #119

Allow to specify a custom repo for the local cache #119

terencode commented May 8, 2020 •

edited

pbrisbin commented May 8, 2020

terencode commented May 8, 2020

terencode commented May 8, 2020

pbrisbin commented May 8, 2020

atreyasha commented May 8, 2020 •

edited

pbrisbin commented May 8, 2020

atreyasha commented May 8, 2020

terencode commented May 10, 2020

atreyasha commented May 17, 2020

terencode commented May 17, 2020

terencode commented May 17, 2020

atreyasha commented May 17, 2020 •

edited

atreyasha commented May 17, 2020

terencode commented May 17, 2020

atreyasha commented May 17, 2020 •

edited

terencode commented May 17, 2020

atreyasha commented May 17, 2020 •

edited

atreyasha commented May 18, 2020 •

edited

pbrisbin commented May 18, 2020 •

edited

terencode commented May 18, 2020

atreyasha commented May 18, 2020 •

edited

atreyasha commented May 18, 2020

terencode commented May 18, 2020

atreyasha commented May 18, 2020

terencode commented May 18, 2020

atreyasha commented May 18, 2020 •

edited

pbrisbin commented May 18, 2020

atreyasha commented May 18, 2020

pbrisbin commented May 18, 2020

atreyasha commented Aug 23, 2020

Allow to specify a custom repo for the local cache #119

Allow to specify a custom repo for the local cache #119

Comments

terencode commented May 8, 2020 • edited

pbrisbin commented May 8, 2020

terencode commented May 8, 2020

terencode commented May 8, 2020

pbrisbin commented May 8, 2020

atreyasha commented May 8, 2020 • edited

pbrisbin commented May 8, 2020

atreyasha commented May 8, 2020

terencode commented May 10, 2020

atreyasha commented May 17, 2020

terencode commented May 17, 2020

terencode commented May 17, 2020

atreyasha commented May 17, 2020 • edited

atreyasha commented May 17, 2020

terencode commented May 17, 2020

atreyasha commented May 17, 2020 • edited

terencode commented May 17, 2020

atreyasha commented May 17, 2020 • edited

atreyasha commented May 18, 2020 • edited

pbrisbin commented May 18, 2020 • edited

terencode commented May 18, 2020

atreyasha commented May 18, 2020 • edited

atreyasha commented May 18, 2020

terencode commented May 18, 2020

atreyasha commented May 18, 2020

terencode commented May 18, 2020

atreyasha commented May 18, 2020 • edited

pbrisbin commented May 18, 2020

atreyasha commented May 18, 2020

pbrisbin commented May 18, 2020

atreyasha commented Aug 23, 2020

terencode commented May 8, 2020 •

edited

atreyasha commented May 8, 2020 •

edited

atreyasha commented May 17, 2020 •

edited

atreyasha commented May 17, 2020 •

edited

atreyasha commented May 17, 2020 •

edited

atreyasha commented May 18, 2020 •

edited

pbrisbin commented May 18, 2020 •

edited

atreyasha commented May 18, 2020 •

edited

atreyasha commented May 18, 2020 •

edited