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

[Atreya Shankar]

As issue #119 has gotten very long, I am just copying over the relevant discussion points that we could use to improve downgrade further.

1. 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.

   Comment from @pbrisbin:

   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.

   SGTM as well to just include the package database along with the package, such as local (core), local (aur), local (community) etc. I agree about not including the cache paths, it would get too long and cumbersome.

2. Look into include's in /etc/pacman.conf and how we pick up other cache directories.

   Comment from @pbrisbin:

   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

   Agree, this does seem too complex, and IMO the benefits might not justify the costs/effort

3. Consider making a downgrade-specific configuration file to set defaults.

   Comment from @pbrisbin:

   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.

   a. I have two perspectives on this. Firstly: yes, the idea of setting environmental variables sounds nice. If we go with this idea, it would be nice if we could include instructions on customizing environmental variables for modifying default behaviours -> perhaps we could include this in the readme or better so, in a GitHub wiki page. PS: I think it will be good to eventually have a wiki page in this repo since we will eventually have diverse functionality in downgrade given version filtering and other cool features.

   b. Alternatively, we could instead get rid of reading environmental variables (from outside downgrade) and only have them as proxies inside downgrade. By doing this, the only way to modify behaviour would be with CLI options, which just makes things IMO tighter and more controlled. A natural extension of this behaviour would be to create configuration files, eg.~/.config/downgrade/downgrade.conf, which would allow the user to set some default behaviours; which would in turn be the sole action that changes environmental variables.

   Personally, I really like (b) because it conforms to the general workflows of many other successful tools out there, and would make downgrade overall more intuitive to customize (based on experiences from others tools).

4. 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.

   We found a non-intrusive way to solve this by running bash -x downgrade. Perhaps this instruction could be added to an issue template regarding bugs in downgrade.

WDYT about these points? If we have an agreement, I would be happy to start working on these first because they seem generally easier than #83 and #118, and also somehow a bit more fundamental to the workflow of downgrade.

[Pat Brisbin]

Thanks for summarizing this.

1. Just to confirm, the decisions here are:

   • Accepting and displaying custom cache paths: i.e. /var/cache/pacman/pkg/firefox-... vs /my/thing/firefox-...: we will support looking in custom directories, but we won't (yet) worry about indicating where a local package is coming from in our output.
   • Displaying the repository for a package (local or remote), e.g. core, community: we will do this.
   • Displaying foreign packages as (aur): we will do this (Note: I think we could just assume foreign == aur, and not bring in any kind of external tool to be "sure").

2. 👍

3. (b) is fine with me! I like using XDG with ~/.config/downgrade/* too. Personally, I'd like to see a man 5 page for the configuration file, instead of a wiki. But I'm not against also having a wiki here for whatever docs we want that don't make sense as manpages.

4. 👍 Issue template makes total sense, regardless of any other decisions.

[Atreya Shankar]

Awesome, am on board. In that case, I will close this issue later on and make separate issues for each task.

Just one quick point:

Accepting and displaying custom cache paths: i.e. /var/cache/pacman/pkg/firefox-... vs /my/thing/firefox-...: we will support looking in custom directories, but we won't (yet) worry about indicating where a local package is coming from in our output.

I believe we already support looking in custom directories with the --pacman-cache option and space-separated paths. For example this should already work:

downgrade --pacman-cache "/var/cache/pacman /my/thing/somewhere" foo

Edit: Only disadvantage with this as of now is that tilde expansions are not supported inside double quotes, which some might find inconvenient. We can probably parse the input string into a bash array and then expand all the inputs paths before feeding them to find.

[Pat Brisbin]

custom directories with the --pacman-cache option and space-separated paths

tilde expansions are not supported inside double quotes

I think the solution is to accept multiple --pacman-cache options:

downgrade
  --pacman-cache /var/cache/pacman \
  --pacman-cache ~/my/thing/somewhere \
  foo

parse the input string into a bash array and then expand

That sounds like a bad idea 😄

[Atreya Shankar]

Closing this issue in favor of #135, #136, #137 and #138