IgnorePkg incorrectly added if IgnorePkg string is not already in config file about downgrade HOT 4 CLOSED

@karjonas thanks for reporting this bug. I am able to reproduce it.

@pbrisbin a fix for this might be relevant to #158 (comment). Right now we are using "manual" approaches with sed to augment the IgnorePkg directive. An external tool for updatiing pacman.conf, similar to pacman-conf for querying, would be super helpful here. I will look through the docs again to see if anything already exists.

https://github.com/pbrisbin/downgrade/blob/14a8bf7d4281877c72f686e3f15acd9c4680a93c/downgrade#L112-L126

from downgrade.

I googled a bit for the best way to parse an ini file from Bash... There seems to be no standalone coreutil-ish thing we could use, so the options would be to either improve/exted our bespoke handling (possibly copying some StackOverflow monstrosity) or somehow use python.

I agree if we're going to increase the complexity of our own "parsing", slicing off a distinct executable would be helpful as a new testable/readable boundary -- however, I'd like to slightly tweak my "contribute upstream" suggestion. I didn't realize at the time that pacman-conf existed (it may not have), hence my suggestion of a new tool in the pacutils space.

An external tool for updatiing pacman.conf, similar to pacman-conf for querying, would be super helpful here

I feel like, ideally, pacman-conf should just be that tool -- i.e. contribute "update in place" support to that tool itself. It would probably be prudent to find an email list to ask if they'd be open to such a contribution first, and I'd imagine that tool is in C, which could be a hurdle.

But again, that'd be the ideal "best for the world given unlimited effort" option, and simply improving our current approach in Bash, to solve only this bug in particular, sounds perfectly reasonable.

from downgrade.

Thoughts

I feel like, ideally, pacman-conf should just be that tool

that'd be the ideal "best for the world given unlimited effort" option

That would indeed be the best case scenario. Here is the GitLab repo for pacman: https://gitlab.archlinux.org/pacman/pacman/

And indeed, pacman-conf is implemented in C: https://gitlab.archlinux.org/pacman/pacman/-/blob/master/src/pacman/pacman-conf.c

prudent to find an email list

Yes, we could do that here: https://lists.archlinux.org/listinfo/pacman-dev

I was trying to search the archives for similar discussions but could not find a centralized way of searching: https://lists.archlinux.org/pipermail/pacman-dev/

In any case, it would be nice to get this discussion into the mailing list for feedback

simply improving our current approach in Bash, to solve only this bug in particular, sounds perfectly reasonable.

Agree that this would be a good short-term fix using bash alone, with the long-term fix being a patch upstream.

(possibly copying some StackOverflow monstrosity)

😆

Ideas

Proposed workflow for solving this issue:

1. We perform a quick fix by modifying our workflow in downgrade. One example could be by adding an additional if-block above line 125. In this additional if-block, we could check for the existence of the [options] header and then augment the IgnorePkg directive directly below the header:

   ln="$(grep -n '^ *\[options\]' "$PACMAN_CONF" | cut -d : -f 1)"
   if [ -n "$ln" ]; then
     sed -i "$ln s/.*/&\\nIgnorePkg = $pkg/" "$PACMAN_CONF"
     continue
   fi
   
   printf "IgnorePkg = %s\\n" "$pkg" >>"$PACMAN_CONF"
   

2. We search the mailing list archives and issues for possible duplicates of this discussion. If there are none, we send out an email to the pacman-dev and/or pacman-contrib (https://lists.archlinux.org/listinfo/pacman-contrib) mailing list requesting for their feedback on a possible patch. The reason I add pacman-contrib here is that it might be easier (effort and approval-time wise; see several old issues related to IgnorePkg) to submit a new pacignore script there rather than overhaul pacman-conf altogether with "editing" features on top of the existing querying ones. We leave this issue open until we resolve the discussion upstream.

WDYT?

from downgrade.

1- SGTM. I would make sure we get good tests in place, and that we're covering this Issue. Then, the "how" of it is less important to me.

2- Defer to you. I didn't realize pacman-conf was in pacman proper, and not also -contrib. It makes sense it might be easier to get a new thing into -contrib than a change into pacman, but it does seem like more of a pacman-conf responsibility to me so I'd personally try the -dev ML first and 🤞 they're receptive.

from downgrade.