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. > 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
