Den ons 3 juni 2026 kl 12:04 skrev Timofei Zhakov <[email protected]>:
> On Wed, Jun 3, 2026 at 11:06 AM Branko Čibej <[email protected]> wrote: > >> On 3. 6. 2026 10:46, Haixiao Yan via dev wrote: >> >> Hi, >> >> I'd like to report an issue with the revision-install target in >> subversion's >> top-level Makefile.in. >> >> Problem >> ------- >> >> When cross-compiling subversion for an x86-64 target on an x86-64 build >> host >> (as done in Yocto/OpenEmbedded), with both 64-bit and 32-bit (multilib) >> builds enabled, the revision-install target generates inconsistent >> content in >> svn-revision.txt, causing an RPM file conflict during image assembly. >> >> The target logic is: >> >> (subversion/svnversion/svnversion $(top_srcdir) 2> /dev/null || \ >> svnversion $(top_srcdir) 2> /dev/null || \ >> echo "unknown"; \ >> ) > $(DESTDIR)$(includedir)/subversion-1/svn-revision.txt >> >> 64-bit build: >> The cross-compiled svnversion binary has the same architecture as the >> build host (x86-64). The libtool wrapper script sets LD_LIBRARY_PATH to >> the >> build directory's .libs, and the host has libapr1 installed. As a >> result, >> svnversion executes successfully and outputs "Unversioned directory" >> (since the source is a release tarball with no SVN metadata). >> >> 32-bit (lib32) build: >> The cross-compiled svnversion is a 32-bit ELF binary. It cannot find >> the >> 32-bit libapr1 on the host, so it fails. The host does not have the >> svnversion tool installed either, so the fallback produces "unknown". >> >> The two packages (subversion-dev and lib32-subversion-dev) both install >> /usr/include/subversion-1/svn-revision.txt with different content, >> causing >> an RPM transaction conflict: >> >> file /usr/include/subversion-1/svn-revision.txt conflicts between >> attempted installs of lib32-subversion-dev and subversion-dev >> >> >> Root Cause >> ---------- >> >> The revision-install target attempts to run the just-built svnversion >> binary >> during make install. This is unreliable across platforms: >> >> - On Linux x86-64 cross-compile with multilib, the 64-bit binary happens >> to >> run successfully while the 32-bit one does not, producing inconsistent >> results. >> >> >> Proposed Fix >> ------------ >> >> Since the source is always a release tarball with no SVN metadata, the >> correct and only meaningful value is "unknown". The svnversion >> invocations serve no >> purpose in this context and should be removed: >> >> revision-install: >> test -d $(DESTDIR)$(includedir)/subversion-1 || \ >> $(MKDIR) $(DESTDIR)$(includedir)/subversion-1 >> echo "unknown" > >> $(DESTDIR)$(includedir)/subversion-1/svn-revision.txt >> >> >> Environment >> ----------- >> >> Build host: Ubuntu 24.04, x86-64 >> Target: qemux86-64 (x86-64 with 32-bit multilib) >> Subversion: 1.14.5 >> Build system: Yocto/OpenEmbedded >> >> >> >> >> I don't even know why we have this revision-install target. It appeared >> all the way back in r844420 along with the 'svnversion' program with no >> justification other than something along the lines of "because we can". >> >> I propose we remove the revision-install target, given that it makes no >> sense at all when installing from a release tarball – which is by far the >> most common way. >> >> > +1 to remove it. I think we already have revision information in 'svn > --version' when using tarball/tags. > Don't see a reason to keep it. Ubuntu don't ship this file (at least it isn't installed on my system), no idea about other distributions but as Timofei say, we have the revision in --version. /Daniel > > >> With regards to multilib or any other downstream packaging, I don't see >> how there's not much we can do; we don't maintain RPM or DEB or any other >> package rules. >> >> >> -- Brane >> >> > > -- > Timofei Zhakov >
