paludis saves the bash readonly variable BASH_REMATCH, when set during, in /var/db/pkg/.../environment.bz2 which blocks cleaning of re-installed or upgraded packages

[sven.mattisson@…]

When a bash regexp has been used in, e.g., a login file (i.e. a ... =~ ... clause) the readonly variable BASH_REMATCH is created. This variable will subsequently be stored in the /var/db/pkg database in the package environment.bz2 file. In a fresh install nothing happens but when the package is upgraded or re-installed the paludis cleaning of the /tmp/paludis/…/package directory fails when the environment is sourced and the install is aborted leaving the package database in a messy state (with …/-checking-package or …/-reinstall-package directories left).

One suggested fix (untried) is to add BASH_REMATCH to the exception list in the function builtin_saveenv in the file /usr/libexec/paludis/builtin_saveenv.bash.

To trigger the problem try: # echo 'if 1 =~ 2 ; then echo "now BASH_REMATCH willb eset"; fi' >> /etc/profile # paludis -1i app-arch/gzip # paludis -1i app-arch/gzip

The regexp test in /etc/profile sets the shell variable, then the first merge writes it to the environment file in the data base, and the second merge fails. Removing the test from /etc/profile and re-merging is not sufficient as the renaming of …/-reinstalling-package to …/package fails. An uninstall followed by an install works however. This problem can probably be triggered by other readonly variables as well.

Best regards,

Sven

[Christian Boos]

This is not the right Trac, you're looking for ​http://paludis.pioto.org/trac/

However, the paludis Trac seems to be offline right now because of a problem which looks like being #4043 but with sqlite.

I'm getting in touch with the admins there and update this ticket when the problem gets fixed.

[Christian Boos]

(your original description)

When a bash regexp has been used in, e.g., a login file (i.e. a [[ ... =~ ...]] clause) the readonly variable BASH_REMATCH is created.  This variable will subsequently be stored in the /var/db/pkg database in the package environment.bz2 file.  In a fresh install nothing happens but when the package is upgraded or re-installed the paludis cleaning of the /tmp/paludis/.../package directory fails when the environment is sourced and the install is aborted leaving the package database in a messy state (with .../-checking-package or .../-reinstall-package directories left).

One suggested fix (untried) is to add BASH_REMATCH to the exception list in the function builtin_saveenv in the file /usr/libexec/paludis/builtin_saveenv.bash.

To trigger the problem try:
# echo 'if [[ 1 =~ 2 ]]; then echo "now BASH_REMATCH willb eset"; fi' >> /etc/profile
# paludis -1i app-arch/gzip
# paludis -1i app-arch/gzip

The regexp test in /etc/profile sets the shell variable, then the first merge writes it to the environment file in the data base, and the second merge fails.  Removing the test from /etc/profile and re-merging is not sufficient as the renaming of .../-reinstalling-package to .../package fails.  An uninstall followed by an install works however.  This problem can probably be triggered by other readonly variables as well.

Best regards,

Sven