[Bug 1202786] New: RPM scriptlets not compatible with obs_scm
https://bugzilla.suse.com/show_bug.cgi?id=1202786 Bug ID: 1202786 Summary: RPM scriptlets not compatible with obs_scm Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: x86-64 OS: openSUSE Leap 15.4 Status: NEW Severity: Minor Priority: P5 - None Component: Development Assignee: screening-team-bugs@suse.de Reporter: georg.pfuetzenreuter@suse.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- Hello! I am unsure whether upstream RPM would be a better fit for this issue, however since it is partially related to behavior introduced by SUSE's obs_scm, I decided to post this here: Certain RPM macros make use of %pre/%post scriptlets, invoked using `%pre/%post -f <file>` - one good example which I will use here are the `sysuser` macros, which generate a dynamic %pre scriptlet during build. This works fine in traditional spec files, however if obs_scm with is used as the single source, following the instructions in https://openbuildservice.org/help/manuals/obs-user-guide/cha.obs.best-practi..., this fails, as RPM tries to locate the `%pre -f` scriptlet in a bogus directory: ``` Source0: _service %prep %setup -q -n %{_sourcedir}/%{appname}-%{version} -T -D %build %sysusers_generate_pre %{SOURCE1} %{appname} system-user-%{appname}.conf RPM build errors: Could not open Postin file /home/abuild/rpmbuild/BUILD/home/abuild/rpmbuild/SOURCES/Limnoria-20220814/limnoria.pre: No such file or directory ``` Notice how it prepends the SOURCES plus the BUILD directory in front of the .pre file, instead of simply referencing the working directory, which would be the build directory (where the .pre file was correctly placed in by the %sysusers_generate_pre macro, as confirmed by inspecting the broken build environment). A workaround is to use the obs recompress service to get a .tar.gz source, which one then uses a "traditional" `%setup` call for. However, I deem this should not be necessary just to get `%pre/post -f` scriptlets to be referenced from the correct working directory. A second work around is to dump the contents of the generated .pre file and pasting them directly into the section without the `-f <file>` call - but that defeats the point of having a generated/dynamic scriptlet. I attempted to supply the full path to `-f` as well, and confirmed it's location, however it would still prepend the bogus directory. You can find a sample .spec file here, however it may change at will, since I am actively working on it: https://build.opensuse.org/package/view_file/home:crameleon:LibertaCasa/pyth... Best, Georg -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202786 Chenzi Cao <chcao@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|screening-team-bugs@suse.de |mls@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202786 Michael Schr�der <mls@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|mls@suse.com |lnussel@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202786 https://bugzilla.suse.com/show_bug.cgi?id=1202786#c1 Ludwig Nussel <lnussel@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |adrian.schroeter@suse.com, | |lnussel@suse.com, | |mls@suse.com Assignee|lnussel@suse.com |adrian.schroeter@suse.com --- Comment #1 from Ludwig Nussel <lnussel@suse.com> --- I suppose you had "%pre -f limnoria.pre" in your spec file. RPM reads relative file names from %_builddir/%buildsubdir, ie %buildsubdir needs to be relative: https://github.com/rpm-software-management/rpm/blob/6761c39063c88a79124e22e7... The parameter to %setup -n defines %buildsubdir: https://github.com/rpm-software-management/rpm/blob/6761c39063c88a79124e22e7... https://github.com/rpm-software-management/rpm/blob/6761c39063c88a79124e22e7... So you specified an absolute name for %buildsubdir but later it's used in a relative way. That doesn't work. You'd have to also specify an absolute path to %pre, ie ""%pre -f %{_sourcedir}/%{appname}-%{version}/limnoria.pre" This explanation should probably be added to the OBS documentation as using %setup that way really is a dirty hack. IMO rpm should simply refuse absolute pathes there. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202786 https://bugzilla.suse.com/show_bug.cgi?id=1202786#c2 --- Comment #2 from Georg Pfuetzenreuter <georg.pfuetzenreuter@suse.com> --- Hi Ludwig, thanks for your input.
I suppose you had "%pre -f limnoria.pre" in your spec file
Correct.
You'd have to also specify an absolute path
That's what I meant with having attempted the "full path" - it still prepended the other bogus path. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202786 https://bugzilla.suse.com/show_bug.cgi?id=1202786#c3 --- Comment #3 from Ludwig Nussel <lnussel@suse.com> --- Works for me (on TW): --->8--- $ cat > ~/rpmbuild/SOURCES/dummy.spec <<EOF Name: dummy Version: 1 Release: 0 Summary: Lorem ipsum License: MIT BuildArch: noarch %description Lorem ipsum %prep %setup -n %_sourcedir -D -T echo "u dummy - "dummy" /var/lib/empty" > dummy.conf %sysusers_generate_pre dummy.conf dummy dummy.conf %build %pre -f %_sourcedir/dummy.pre %files %changelog EOF $ rpmbuild -bb ~/rpmbuild/SOURCES/dummy.spec $ rpm -qp --scripts ~/rpmbuild/RPMS/noarch/dummy-1-0.noarch.rpm preinstall scriptlet (using /bin/sh): /usr/sbin/sysusers2shadow dummy.conf <<"EOF" || [ -f /.buildenv ] u dummy - dummy /var/lib/empty EOF --->8--- -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202786 https://bugzilla.suse.com/show_bug.cgi?id=1202786#c4 --- Comment #4 from Georg Pfuetzenreuter <georg.pfuetzenreuter@suse.com> --- Interesting. It indeed works with your dummy example on Tumbleweed (not on 15.4, but that seems to be a different issue). With my python-limnoria package however: %pre -f %{_sourcedir}/%{name}.pre RPM build errors: Could not open Prein file /home/abuild/rpmbuild/BUILD/home/abuild/rpmbuild/SOURCES/Limnoria-20220814/home/abuild/rpmbuild/SOURCES/python-limnoria.pre: No such file or directory I suppose that's some peculiarity with my package and out of scope of this bug then. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202786 https://bugzilla.suse.com/show_bug.cgi?id=1202786#c5 --- Comment #5 from Georg Pfuetzenreuter <georg.pfuetzenreuter@suse.com> --- The workaround to specify the full path to `%pre -f` seems to only work for some packages, but I have not yet determined a pattern. Interestingly, today I started noticing packages with the same behavior, but rpmbuild would not return the "correct wrong" path, i.e. it would print the path passed to `%pre -f`, at which the script file existed, in the error message, but `strace` revealed it was secretly trying to read from the wrong path again: ``` strace out: openat(AT_FDCWD, "/home/abuild/rpmbuild/BUILD/home/abuild/rpmbuild/SOURCES/salt-netbox-roleproxy-git+5a73a8a/home/abuild/rpmbu ild/SOURCES/salt-netbox-roleproxy-git+5a73a8a/roleproxy.pre", O_RDONLY) = -1 ENOENT (No such file or directory) rpmbuild out: error: Could not open Prein file: /home/abuild/rpmbuild/SOURCES/salt-netbox-roleproxy-git+5a73a8a/roleproxy.pre Could not open Prein file: /home/abuild/rpmbuild/SOURCES/salt-netbox-roleproxy-git+5a73a8a/roleproxy.pre ``` -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202786 https://bugzilla.suse.com/show_bug.cgi?id=1202786#c6 --- Comment #6 from Georg Pfuetzenreuter <georg.pfuetzenreuter@suse.com> --- Upon discussion in #opensuse-packaging, I found a hack which seems to work in all cases where the originally suggested workaround does not seem to work. ``` %prep mv %{_sourcedir}/%{name}-%{version}/* . ``` This moves the sources to BUILD, where `%pre -f` happily executes scripts from. Since the documentation in https://openbuildservice.org/help/manuals/obs-user-guide/cha.obs.best-practi... about using the `-T -D` options to %setup is technically suggesting a hack as well, maybe we should update it to use the `mv` hack instead? -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠suse.com