Date: Tue, 02 Jul 2019 21:24:37 +0200 From: Baptiste Daroussin <bapt@FreeBSD.org> To: "Timur I. Bakeyev" <timur@freebsd.org> Cc: =?UTF-8?Q?T=C4=B3l_Coosemans?= <tijl@freebsd.org>, ports-committers@freebsd.org, svn-ports-all <svn-ports-all@freebsd.org>, svn-ports-head <svn-ports-head@freebsd.org> Subject: Re: svn commit: r504590 - in head/net: samba46 samba47 samba48 Message-ID: <38AAD2AA-702E-4285-8C77-22DEB00810B6@FreeBSD.org> In-Reply-To: <CALdFvJELwpc8MVzuEEhCuAWL3-UKz1_dPd%2BAuzr%2BcUynoUgzsg@mail.gmail.com> References: <201906192240.x5JMequU017187@repo.freebsd.org> <20190628070305.eim4o3d77iyti5d5@ivaldir.net> <20190629160445.051f2426@kalimero.tijl.coosemans.org> <CALdFvJHK0aBF6oLTFNnTiUyrmFUHCPYm3-k7S3_-FpYTHW4WSA@mail.gmail.com> <F208C261-18D8-4E5A-BABE-A9E6D8A52B5B@FreeBSD.org> <CALdFvJENynqPAkKSf5ueuG2nBMr9tckikzZOQv9caXtgcwZg4A@mail.gmail.com> <20190702141756.1f0b14b7@kalimero.tijl.coosemans.org> <20190702122219.lqecdgrgpkhtkeqk@ivaldir.net> <CALdFvJELwpc8MVzuEEhCuAWL3-UKz1_dPd%2BAuzr%2BcUynoUgzsg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Le 2 juillet 2019 20:45:21 GMT+02:00, "Timur I=2E Bakeyev" <timur@freebsd=
=2Eorg> a =C3=A9crit :
>On Tue, 2 Jul 2019 at 20:26, Baptiste Daroussin <bapt@freebsd=2Eorg>
>wrote:
>
>> On Tue, Jul 02, 2019 at 02:17:56PM +0200, T=C4=B3l Coosemans wrote:
>> > On Mon, 1 Jul 2019 01:23:34 +0200 "Timur I=2E Bakeyev"
><timur@freebsd=2Eorg>
>> > wrote:
>> > > On Sat, 29 Jun 2019 at 22:50, Baptiste Daroussin
><bapt@freebsd=2Eorg>
>> wrote:
>> > >> Le 29 juin 2019 20:40:53 GMT+02:00, "Timur I=2E Bakeyev"
><timur@bat=2Eru>
>> a
>> > >> =C3=A9crit :
>> > >>> Tonight I hope to commit 4=2E10 port=2E
>> > >>
>> > >> 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=2E
>> > >
>> > > 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=2E The biggest difference is the drop of the dependency on
>> Python27,
>> > > as far as I can see=2E
>> > >
>> > > New Samba port doesn't use external databases/ldb*, so
>security/sssd
>> may
>> > > use any of those freely now=2E
>> > >
>> > > The samba4[47] are outdated and should disappear in the middle of
>the
>> > > August=2E
>> > >
>> > > The samba48 will remain for a while, but not for long, as
>samba411 us
>> > > pushing from behind=2E It'll be (hopefully)
>> > > the only consumer of the talloc1/tevent1/tdb1 ports, which should
>> disappear
>> > > together with Samba 4=2E8=2E
>> > >
>> > > In general I'd prefer to see SAMBA_DEFAULT to be bumped to 410,
>but
>> this is
>> > > up to the portmgr=2E
>> >
>> > 4=2E8 goes EoL upstream mid-September (about 2 weeks before Q4), so
>> > making 4=2E10 now would be good, but I believe it's just too late for
>> > that=2E A port like this needs at least a few weeks of wider testing
>> > before it can be pushed to users of the quarterly branches who
>expect
>> > more stability=2E
>> >
>> > Since you said that the new libs are API compatible, is it possible
>to
>> > make 4=2E8 use the new libs? If not, then all non-samba consumers
>will
>> > have to switch to the legacy libs=2E They can be switched back after
>the
>> > 2019Q3 branch has been created (together with making 4=2E10 the
>default
>> > which probably needs an exp-run)=2E
>>
>> It is and I tried to build everything with the new lib=2E the problem I
>am
>> stuck
>> with is the following, to have ldb12 building with new talloc, I need
>to
>> build
>> it without python, but I don't know what is the impact of that to end
>> users=2E
>>
>> My understading is any samba should be able to run with any ldb
>version
>> which
>> makes me wonder why we have that many version in the tree instead of
>> always the
>> latest one=2E
>>
>
>No, you are wrong=2E It MAY look like the LDB libs are almost the same
>crom
>1=2E1-1=2E6 branches,
>but there is the reason why developers don't stick to one branch cross
>different versions of
>Samba=2E
>
>At least, NO ONE gives the guarantee, that the intermix of LDB and
>Samba
>versions will
>work as intended and you won't hit any obscure and hard to pin point
>bugs=2E
>We went through
>that when Perl-Parse-Pidl was used cross several versions of Samba and
>the
>results were
>disastrous=2E
>
Thanks for clarification!
>
>> For the set of library yes they are fully backward compatible
>according to:
>> https://abi-laboratory=2Epro/index=2Ephp?view=3Dtimeline&l=3Dtalloc
>> https://abi-laboratory=2Epro/index=2Ephp?view=3Dtimeline&l=3Dtevent
>> https://abi-laboratory=2Epro/index=2Ephp?view=3Dtimeline&l=3Dtdb
>>
>> the problem is on the python binding if any=2E
>>
>> The current situation is a big mess for end users of those libraries!
>>
>
>Here I absolutely agree=2EThe said commit was trying to put in line all
>the
>consumers of the related libraries,
>leaving legacy to where it belongs - behind, but we got unhappy Matt=2E
>
>As an effort to address concerns of Samba 4=2E8 users I altered the port,
>with few knobs set to completely
>build with the bundled libraries, not using any from outside=2E
>
>I hope this is good enough solution for those, who want to have a
>mixture
>of Samba 4=2E8, SSSD and other consumers
>of talloc/tdb/ldb in one system=2E
>
>My only concern now - should it be the default for the port or just
>documented in the UPDATING?
>
>With regards,
>Timur
I haven t checked yet your commit, will do tomorrow, this sounds like a go=
od fix if the default is to bundle ( the build packages use the default opt=
ions)
If not can you make it default so we can branch the quarterly, and start b=
uilding packages ?
Thank you,
Best regards,
Bapt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?38AAD2AA-702E-4285-8C77-22DEB00810B6>