Bug 235935 - devel/subversion: version selection via DEFAULT_VERSIONS
Summary: devel/subversion: version selection via DEFAULT_VERSIONS
Status: Closed Overcome By Events
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: Lev A. Serebryakov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-02-22 11:08 UTC by Michael Osipov
Modified: 2023-09-22 09:29 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (lev)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Osipov 2019-02-22 11:08:11 UTC
It should be possible to say DEFAULT_VERSIONS+=subversion=1.10 etc. instead of WITH_SUBVERSION_VER=19. The approach can be copied from many other ports. The default version shall be 1.10 which is an LTS version.
Comment 1 Lev A. Serebryakov freebsd_committer freebsd_triage 2019-02-22 12:55:44 UTC
DEFAULT_VERSIONS — I agree, I need to investigate how to do this (BTW, there is no "subversion" meta-port like "python", to install default version as dependency)

1.10 as default — I don't like it, to be honest.
Comment 2 Michael Osipov 2019-02-22 13:13:39 UTC
(In reply to Lev A. Serebryakov from comment #1)

Why not turn devel/subversion into a metaport and move the current one to devel/subversion111? That should be the way to go, shouldn't it?

Why not 1.10? It is the latest stable LTS release. 1.11 will die soon, I don't think that people want to constantly have that change. The roadmap pretty much desribes the selected approach: http://subversion.apache.org/roadmap.html#release-planning. I think this is the best we can offer in stability by default.
Comment 3 Lev A. Serebryakov freebsd_committer freebsd_triage 2019-02-25 10:24:08 UTC
(In reply to Michael Osipov from comment #2)
Problem not with devel/subversion but with all additional sub-ports (langauge bindings, keystore acsessors and apache's module). And they could not be FLAVOR'ed because Python is FLAVOR'ed already and py-subversion can not have two FLAVORs.

About 1.10 as default: sorry, I don;t buy "LTS" thing and "dead in 6 months" thing. Yes. And so what?! What is additional value not-to-upgrade for typical user? Subversion is known for very strong backward compatibility, and you could use 1.11 and, I'm sure, will be able to use 1.12 and 1.13 clients with 1.10 server and vice versa (!). Why did typical user want to stick with LTS? I don't understand.
Comment 4 Michael Osipov 2019-02-25 12:01:24 UTC
(In reply to Lev A. Serebryakov from comment #3)

If I understand you correctly, "DEFAULT_VERSIONS+=subversion=x.y" will not be possible one has to live with "WITH_SUBVERSION_VER=xy?

I not really worried about clients. Guess what, our server was silently upgraded from 1.9 to 1.10 and the mod_dav_svn stopped serving the repos for appearenly no reason. Moreover, the authz file format has been tightened and revisited in recent versions, causing some compat issues you can read on the dev mailing list.

My reasoninng is POLA. With your argumentation your can say that the default version of Python must be 3.7 which it isn't, it is 3.6 for, probably, a good reason.
Comment 5 Lev A. Serebryakov freebsd_committer freebsd_triage 2019-02-25 12:15:18 UTC
(In reply to Michael Osipov from comment #4)
DEFAULT_VERSIONS is possible, but not-so-useful as other DEFAULT_VERSIONS, as there is no way to have two version of subversion & addons installed in the system. DEFAULT_VERSIONS will be only one version in this case. I'll do this, I don't have objections to use "standard" method to choose desired version, but right now I don't have time to spare to this/. Maybe, this week later or week after this one.

So, DEFAULT_VERSIONS in case of subversion will dictate which version of addons will be built by default build cluster to be available as binary packages.

It is why I don't like it set not to latest version: our binary package repository will contain all subversion versions (as they are different, distinct ports), but only DEFAULT_VERSIONS-dictated addons. I think, it is better to have binary packages for latest addons, not LTS one.

And your example about silent update is not applicable here: as soon as we'll have "subversion-lts" port (which will contain 1.10 for now), it will not be silently updated till next LTS release. You will need to use it, not "subversion" port which will contain newest version available.
Comment 6 Michael Osipov 2019-02-25 12:52:22 UTC
I will leave the DEFAULT_VERSIONS decision upto you because have more insight. I don't expect a solution in the next couple of weeks. Just wanted to point out that from a user's perspective it is counter-intuitive.

> It is why I don't like it set not to latest version: our binary package repository will contain all subversion versions (as they are different, distinct ports), but only DEFAULT_VERSIONS-dictated addons. I think, it is better to have binary packages for latest addons, not LTS one.

I do not have personally proper opinion on, but I'd like you to take the following into consideration:

* If you strive for the latests versions, then all versions in the mk file should be the latest for the sake of consistency
* By not setting the default version I trust the portmaintainer not to introduce breaking changes making me to invest two days to fix that, it should cause, at most, a minor outage

> And your example about silent update is not applicable here: as soon as we'll have "subversion-lts" port (which will contain 1.10 for now), it will not be silently updated till next LTS release. You will need to use it, not "subversion" port which will contain newest version available.

That is correct, but on both cases you have to rely on the port maintainer to bump bleeding and LTS in the defaults makefile. Take also into consideration that between LTS versions will be at least two years. This is more that realistic for a port maintainer to prepare such a change. What will you do if you rapidly replace 1.11 with 1.12, the 1.11 port is gone and the use hits a bug? There is no way to rollback unless go back with Subversion. There will be always pros and cons.
Comment 7 Lev A. Serebryakov freebsd_committer freebsd_triage 2019-04-25 18:21:47 UTC
Hmm, I bump into bug problem with DEFAULT_VERSIONS: to use it bsd.port.pre.mk should be included very early, before we could set needed options (like unsig bzip2 and not gzip for distfile) and it breaks port...

I don't see good solution for this problem.
Comment 8 Olli Hauer freebsd_committer freebsd_triage 2019-05-01 15:45:34 UTC
I remember I've done a POC many years ago ...
https://lists.freebsd.org/pipermail/freebsd-ports/2011-July/068561.html

Perhaps it can be used with much work to convert it into Uses/svn.mk
https://people.freebsd.org/~ohauer/diffs/Mk_bsd.port.mk/

Regarding the default version:
 Running SVN over TLS (mod_dav_svn) so partners can develop together with us.
 From 1.6.x to 1.9.x subversion was unluckily most unusable if miner version was not at last .5 or higher
 (I had to often run an own pkg tree with modifications to overcome subversion issues)
Comment 9 Olli Hauer freebsd_committer freebsd_triage 2019-05-01 16:28:16 UTC
Found the old framework PR bug #157852
Comment 10 Lev A. Serebryakov freebsd_committer freebsd_triage 2019-05-06 11:48:37 UTC
(In reply to Olli Hauer from comment #8)
I'm trying to do Mk/Uses/svn.mk (it is only official way to use DEAFULT_VERSIONS), but I have chicken-and-egg problem for addons: ${SUBVERSIONPORT}/Makefile.common uses USES and other infrastructure which is too late for Mk/Uses/ infrastructure!

I can not find good solution yet :-(

I'll look at your POC.
Comment 11 Michael Osipov 2023-09-22 09:29:54 UTC
I am closing this for the following reasons:
* There hasn't been done for years
* The Subversion team does not massproduce new releases

We can basically have only two ports in the tree:
* devel/subversion-lts which is the last LTS version even if there are several ones
* devel/subversion which is the latest current version even if there are several ones

The overhead of managing of more than two ports isn't not justified at all in this case.