[MDEV-31480] RPM packages fail to install because they require /bin/sh for %pretrans Created: 2023-06-14  Updated: 2023-06-30  Resolved: 2023-06-30

Status: Closed
Project: MariaDB Server
Component/s: Packaging, Platform RedHat
Affects Version/s: 10.4.29, 10.4.30
Fix Version/s: 10.4.31, 10.5.22, 10.6.15, 10.9.8, 10.10.6, 10.11.5, 11.0.3

Type: Bug Priority: Major
Reporter: Raynard Sandwick Assignee: Sergei Golubchik
Resolution: Fixed Votes: 0
Labels: packaging, rpm
Environment:

CentOS 8 initial Anaconda+DNF transaction



 Description   

The RPM packages for 10.4.29 and 10.4.30 under:

https://mirror.mariadb.org/yum/10.4/centos8-amd64/rpms/

have added a %pretrans scriptlet interpreter requirement of /bin/sh. This makes it impossible to add them to a clean initial installation transaction (e.g., including them on a custom ISO for kickstarted install, or adding them to a fully clean bootstrap with an uninitialized rpmdb for OCI/similar builds).

Given that none of the packages appear to have a non-empty %pretrans scriptlet, and given that no RPM should ever use an interpreter other than the embedded Lua engine during %pretrans, whichever tool is being used to create these RPMs should be configured to omit any requirement for %pretrans time.

Quick script showing the problem:

$ cat show-mariadb-pretrans 
#!/bin/sh
ls MariaDB*.rpm
echo
tblfmt='%s\t%s\t%s\t%s\n'
{
    versions=( 10.4.28 10.4.29 10.4.30 )
    printf "${tblfmt}" subpackage "${versions[@]}"
    for n in backup client common compat server shared; do
        z=( )
        for v in "${versions[@]}"; do
            f=MariaDB-$n-$v-1.el8.x86_64.rpm
            z+=( "'$(rpm -q --scripts -p $f 2> /dev/null | grep pretrans)'" )
        done
        printf "${tblfmt}" ${n} "${z[@]}"
    done
} | column -o'    ' -s'	' -t
echo
$ ./show-mariadb-pretrans 
MariaDB-backup-10.4.28-1.el8.x86_64.rpm  MariaDB-common-10.4.28-1.el8.x86_64.rpm  MariaDB-server-10.4.28-1.el8.x86_64.rpm
MariaDB-backup-10.4.29-1.el8.x86_64.rpm  MariaDB-common-10.4.29-1.el8.x86_64.rpm  MariaDB-server-10.4.29-1.el8.x86_64.rpm
MariaDB-backup-10.4.30-1.el8.x86_64.rpm  MariaDB-common-10.4.30-1.el8.x86_64.rpm  MariaDB-server-10.4.30-1.el8.x86_64.rpm
MariaDB-client-10.4.28-1.el8.x86_64.rpm  MariaDB-compat-10.4.28-1.el8.x86_64.rpm  MariaDB-shared-10.4.28-1.el8.x86_64.rpm
MariaDB-client-10.4.29-1.el8.x86_64.rpm  MariaDB-compat-10.4.29-1.el8.x86_64.rpm  MariaDB-shared-10.4.29-1.el8.x86_64.rpm
MariaDB-client-10.4.30-1.el8.x86_64.rpm  MariaDB-compat-10.4.30-1.el8.x86_64.rpm  MariaDB-shared-10.4.30-1.el8.x86_64.rpm
 
subpackage    10.4.28    10.4.29                        10.4.30
backup        ''         'pretrans program: /bin/sh'    'pretrans program: /bin/sh'
client        ''         'pretrans program: /bin/sh'    'pretrans program: /bin/sh'
common        ''         'pretrans program: /bin/sh'    'pretrans program: /bin/sh'
compat        ''         'pretrans program: /bin/sh'    'pretrans program: /bin/sh'
server        ''         'pretrans program: /bin/sh'    'pretrans program: /bin/sh'
shared        ''         'pretrans program: /bin/sh'    'pretrans program: /bin/sh'
 
$ 

I wasn't sure if the MDEV project was the right place for this, being a packaging concern rather than a "real" bug, but I didn't see a more appropriate-looking spot for it, sorry if I missed something.



 Comments   
Comment by Sergei Golubchik [ 2023-06-29 ]

It turned out that 10.4.28 was built with cmake 3.11.4 and 10.4.29 was built with the latest (in rhel8 repos) cmake 3.20.2.

In 3.18 cpack got the support of %pretrans and %posttrans scriptlets: https://cmake.org/cmake/help/v3.18/release/3.18.html#cpack

I think this could be qualified as a cmake bug. I'll report it to kitware/cmake

Comment by Raynard Sandwick [ 2023-06-29 ]

Ah, I see, that makes sense. It does look like fpm ran into it also, a few years back: https://github.com/jordansissel/fpm/issues/1666

I'll be happy to put in supporting comments on a cmake issue as well, though I wouldn't know how to write it up initially since I'm totally unfamiliar with cpack. Thanks for digging into this!

Comment by Sergei Golubchik [ 2023-06-30 ]

I've implemented a workaround

Generated at Thu Feb 08 10:24:12 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.