The documentation insists on not using tarballs for short lived builds, which is perfect for icon themes because you are able to fetch either the source form the main repository branch or any published tag (obs_scm).
I visited other OBS repositories to learn some practices, but almost all icon themes still use tarballs. But the documentation delivers hello world quality information on the topic the authors themselves introduced.
My specfile installation instructions are very simple:
%install
cd %_sourcedir/%name-%version
./install.sh -d %{buildroot}%{_datadir}/icons -s all -t all
%fdupes %{buildroot}%{_datadir}/icons
Building the package against OpenSUSE_Slowroll goes well, even a Linking step outputs some useful information about what’s going on at build-level only to fail later with multiple outputs like:
[ 381s] calling /usr/lib/rpm/brp-suse.d/brp-05-permissions
[ 381s] calling /usr/lib/rpm/brp-suse.d/brp-15-strip-debug
[ 398s] calling /usr/lib/rpm/brp-suse.d/brp-25-symlink
...
[ 611s] ERROR: link target doesn't exist (neither in build root nor in installed system):
[ 611s] /usr/share/icons/Colloid-Yellow-Nord-Light/mimetypes/scalable/application-x-ms-wim.svg -> ../apps/wine.svg
[ 611s] Add the package providing the target to BuildRequires and Requires
No further information is given. Searching for this (and previous step) errors will land you in the GitHub source code for osc instead of actual useful documentation about such scenarios. Searching the forums will land you on the OBS homepage and more packages that use tarballs.
Is it best to move on to tarballs and suggest wiki maintainers to remove such section from the documentation? Or am I missing a way to tell osc that I don’t care about that brp-25-symlink step and keep building, i’ll fix my mistakes later.
How open is the wiki for changes/contributions regarding the OBS? I’m willing to contribute back my steps in a guide or something because I wouldn’t like to see more entry-level obs package maintainers reading toxic amounts of Python for something that should be as simple as running the included install script.
I noticed that but wouldn’t this workflow also break patches?
I provided a fix-install.patch to ensure the /usr/share/icons path when building, however, calling : %patch0 -p1 after %setup resutls in an earlier build error:
[ 14s] + %patch0 -p1
[ 14s] /var/tmp/rpm-tmp.fQyX7M: line 38: fg: no job control
What’s left for me is to modify the script using sed or any other tool at the %install section of the specfile which might be dirty and out of place. Is this kind of workflow ideal only for builds where one does not want any changes that upstream doesn’t deliver?
rpmlog(RPMLOG_ERR, _("%%patchN is obsolete, "
"use %%patch N (or %%patch -P N): %s\n"), spec->line);
I wonder if it is possible to disable interpretation of % as job control in bash. This would result in slightly more legible error referring to the actual macro name.
Will go back to use a tarball like everyone else, that’s what works and it looks like that’s what should be used despite what the OBS wiki says.
I’ll see if that way it’s easier for me to fix upsteam’s bewitched bash script with a .patch file. No sane amount of awk was enough to force this thing to work and stop whining about symlinks.
I’m sorry for wasting anyone’s time here . I’ll think twice before blindly following some “Draw the rest of the horse” docs next time.
This is upstream bug. The sources contain links that point to the non-existing target. E.g. this link is obviously missing subdirectory of apps. A lot of links point to the mime directory. This software comes with mimetypes directory that does have this file, but it does not have mime directory nor is this directory created during installation.
What else do you want to know? Fix the sources.
Patch file is applied after sources are unpacked. How those sources are made available is completely irrelevant.
Besides, this particular problem does not need any patch file. You simply need to fix those links in the %install section. Either replace them with the correct links (e.g. into mimetypes directory or a suitable subdirectory of apps) or simply remove them. As it is, those links are not functional anyway.
which might be dirty and out of place. Is this kind of workflow ideal only for builds where one does not want any changes that upstream doesn’t deliver?
. I’ll think twice before blindly following some “Draw the rest of the horse” docs next time.