add mergemaster(8) deprecation notice

[emaste]

Other things to update:

• UPDATING
• https://www.freebsd.org/doc/handbook/makeworld.html

[rgrimes]

Relnotes: Y and RELNOTES entry possible too, and with a slight language change MFC to 11 and 12.

usr.sbin/mergemaster/mergemaster.8

49

utility is being deprecated at .Fx 13.0.
Then this can be merged to stable/11 and stable/12?

[emaste]

usr.sbin/mergemaster/mergemaster.8

49

Do you suggest we indicate it's deprecated in 13 and then remove it before 14, or remove in 13?

i.e., what about one of these:

The
.Nm
utility is deprecated and will not be available in
.Fx 13.0.

The
.Nm
utility is deprecated and will not be available in
.Fx 14.0.

etcupdate is available in all supported releases

[rgrimes]

The timing is flexible I think, but my recollection of the current depricaiton policy is since no notice went out in 12.0 the first notice of deprecation should be in the 13 branch and the code is removed in 14. But as I said history has shown us to be pretty flexible especially if we get notice MFC'ed and it goes out in 12.2. So up to you which path you choose.

I do like the text you used.

[rgrimes]

Further note, you should make the utility itself spit out a notice when executed.

[emaste]

Some further discussion has turned up a preference for removing in 13.0, and I'm happy enough with that plan assuming we get the notice in 12.2 and 11.4.

Add a few others who have touched mergemaster as subscribers.

[kevans]

I guess take this acceptance lightly- I've only modified work by Allan, but etcupdate and/or pkg are clearly an improvement based on what I've seen.

[jhb]

I think removing in 13.0 might be a bit aggressive. I've certainly run into several developers who still use this instead of etcupdate. We also haven't updated any of our docs in the handbook to mention etcupdate (wblock@ tried but gave up when he ran into issues I didn't understand when trying to use etcupdate). I do think a runtime warning might also be warranted, though likely to be lost in the noise that mergemaster generates. Making sure the handbook documents etcupdate is probably a prerequisite for deprecating it.

[bapt]

I agree with @jhb on the update of the handbook should hapoen first

[bdrewery]

Why though? Plenty of users still use it. What's the argument for forcing etcupdate over mergemaster? IMHO it's a large burden to users to convert things that use mergemaster fine to etcupdate.

What unsolved problem warrants removal? I assume the argument is "not maintained" which is why I ask what problem exists.

[driesm]

@emaste, do you plan on picking this up again? Removal in 14 seems reasonable. Handbook and UPDATING have been updated since.

[driesm]

In D23327#514406, @bdrewery wrote:

Why though? Plenty of users still use it. What's the argument for forcing etcupdate over mergemaster? IMHO it's a large burden to users to convert things that use mergemaster fine to etcupdate.

What unsolved problem warrants removal? I assume the argument is "not maintained" which is why I ask what problem exists.

As far as I know biggest reasons are included in some PR's (252054).
mergemaster does not work nicely with VCid's being removed because of the git transition (13-release and higher).

https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=mergemaster&list_id=468358

[emaste]

Bump for 14

[gjb]

Perhaps bump .Dd, too, when you are ready to commit.