On 6/4/26 15:35, Branko Čibej wrote:
**
*CAUTION: This email comes from a non Wind River email account!*
Do not click links or open attachments unless you recognize the sender
and know the content is safe.
On 3. 6. 2026 20:42, Daniel Sahlberg wrote:
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
<https://urldefense.com/v3/__http://Makefile.in__;!!AjveYdw8EvQ!cjHh_ys_MAJVqB8VKRmWp_rcVBbgDdAkjs8mm0Eok_9EeJC_9yh6HD0q4Sl00d-Blo2Q2DaZa4vrGhA9mpwI$>.
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.
But only when built from a tarball. :)
Given how we just got served this beautiful, complex patch accompanied
by a wall of text in a separate thread before this discussion even
ended, I'm inclined to push this to downstream packagers; let 'em deal
with it. But, yah, that's just sheer contrariness.
Sorry about the wall of text. It's my first time submitting a patch
here, won't happen again.
Please let me know if any further changes are needed.
Thanks,
Haixiao
However, there's one more question we have to answer: do we remove
this target from 1.14.x as well?
-- Brane
