svn commit: r504590 - in head/net: samba46 samba47 samba48

[Timur I. Bakeyev]

On Mon, 1 Jul 2019 at 09:28, Mathieu Arnold <mat at freebsd.org> wrote:

> On Mon, Jul 01, 2019 at 01:23:34AM +0200, Timur I. Bakeyev wrote:
> > On Sat, 29 Jun 2019 at 22:50, Baptiste Daroussin <bapt at freebsd.org>
> wrote:
> >
> > > Le 29 juin 2019 20:40:53 GMT+02:00, "Timur I. Bakeyev" <timur at bat.ru>
> a
> > > écrit :
> > > >Tonight I hope to commit 4.10 port.
> > >
> > > It does not solve rhe pb, staying on the legacy libs is the solution,
> as I
> > > said even fedora is on the legacy
> > >
> > >
> > I've committed net/samba410.
> >
> > My view on the situation is that all the ports, which use
> > devel/{talloc,tevent}, databases/tdb should keep
> > using them, unless they are broken by using them(but that shouldn't
> happen,
> > API still should remain
> > the same. The biggest difference is the drop of the dependency on
> Python27,
> > as far as I can see.
> >
> > New Samba port doesn't use external databases/ldb*, so security/sssd may
> > use any of those freely now.
> >
> > The samba4[47] are outdated and should disappear in the middle of the
> > August.
> >
> > The samba48 will remain for a while, but not for long, as samba411 us
> > pushing from behind. It'll be (hopefully)
> > the only consumer of the talloc1/tevent1/tdb1 ports, which should
> disappear
> > together with Samba 4.8.
> >
> > In general I'd prefer to see SAMBA_DEFAULT to be bumped to 410, but this
> is
> > up to the portmgr.
>
> So, as you do not seem to be addressing the problem, what do people do
> when they use samba48 and other ports like freeradius3? Right now, they
> cannot.
>

I've committed now r50569, which allow to build port with the statically
linked talloc/tevent/tdb
if there are settings in the /etc/make.conf:

SAMBA4_BUNDLED_TALLOC=          yes
SAMBA4_BUNDLED_TEVENT=          yes
SAMBA4_BUNDLED_TDB=             yes

If that's not enough, those variables can be set within the port itself,
making it self-contained and not
depending on the external versions of the libs in question.

With regards,
Timur.