On Sat, 29 Aug 2026 at 18:05, Daniel Sahlberg <[email protected]>
wrote:

>
>
> lör 29 aug. 2026 kl. 17:12 skrev Ivan Zhakov <[email protected]>:
>
>> On Sat, 29 Aug 2026 at 15:40, Nathan Hartman <[email protected]>
>> wrote:
>>
>>> On Sat, Aug 29, 2026 at 8:08 AM Stefan Sperling <[email protected]> wrote:
>>>
>>>> On Sat, Aug 29, 2026 at 01:50:28PM +0200, Daniel Sahlberg wrote:
>>>> > Should we mention something about Makefile.svn in INSTALL? As Stefan
>>>> says
>>>> > it is maintained and very useful if you want to build Subversion with
>>>> > different dependencies.
>>>>
>>>> I would avoid advertising it to users. It's a development build script,
>>>> not an installation method for production deployments (unless maybe if
>>>> handled by someone who really knows what they are doing and isn't just
>>>> following installation instructions).
>>>
>>>
>>> Agreed that Makefile.svn is a developer-facing tool. One reason it isn't
>>> for building an end-user install: it enables maintainer mode, etc.
>>>
>>> End-users should be using their operating system's package manager to
>>>> install Subbersion. And all the Linux/Unix-like distribution packagers
>>>> already have their own dependency tracking solution. (I'm ignoring
>>>> Windows
>>>> here because get-deps.sh doesn't apply when building on Windows.)
>>>>
>>> I think INSTALL should start by suggesting that the easiest method to
>>> install Subversion is from your distribution's package manager, or by
>>> downloading prebuilt binaries [1]. Then it can say that the rest of this
>>> document is about building from source.
>>>
>>> I'm +1 to remove get-deps.sh.
>>>
>>> I am +1 to remove get-deps.sh. Also I think get-deps.sh doesn't worth to
>> be mentioned in the release notes: it just a developer script.
>>
>
> We already have mentioned the other removed scripts, see
>
> https://subversion-staging.apache.org/docs/release-notes/1.15.html#devscripts
>
>
Good point! I forgot about this section in release notes. Btw I am fine to
remove get-deps.sh in 1.15.x too: it's insecure and unmaintained.

-- 
Ivan Zhakov

Reply via email to