CURRENT, usr/src on git, howto "mergemaster"?

Warner Losh imp at bsdimp.com
Mon Jan 4 19:16:43 UTC 2021


On Mon, Jan 4, 2021 at 12:13 PM Marek Zarychta <
zarychtam at plan-b.pwste.edu.pl> wrote:

> W dniu 04.01.2021 o 19:54, Enji Cooper pisze:
> >
> >> On Jan 4, 2021, at 10:49 AM, Marek Zarychta <
> zarychtam at plan-b.pwste.edu.pl> wrote:
> >
> > …
> >
> >> Terrible idea IMHO, but I am only the weak voice from the userbase.
> >>
> >> It's like deprecating old, well-worn hammer in the favour of the nail
> >> gun. Why not deprecate biff(1), pom(6), nvi(1) etc.?
> >
> > Marek,
> >       I’m curious: have you used etcupdate before instead of
> mergemaster? If so when? If you ran into issues (UX as well as functional):
> could you please report them on bugs.freebsd.org <http://bugs.freebsd.org/>
> ?
> >       etcupdate is a less fragile tool that’s broken my systems less
> when compared with mergemaster.
>
> Dear Enji,
>
> to satisfy your curiosity: Yes, I have tried etcupdate(8) a few times
> over years. It works fine, but I don't like the idea of editing
> conflicted files.
>
> I won't complain about etcupdate(8), but please leave mergemaster(8)
> as is. I believe we need both: solid, fast black boxes driven it auto
> mode and fragile tools in the base. mergemaser is rather not a potential
> security hole in the system.
>

mergemaster is on its way out. Formalizing it by deprecating in 13 means
you'll be able to use it through the end of life of the 13 branch many
years from now. That's plenty of time to move to the new tools and/or
develop enhancements that make them easier for you to use. The knock on
communicating this well is a fair one, and we'll start taking measures to
fix that.

Warner


More information about the freebsd-current mailing list