samba - Oct 2022 - Samba 4.16 and 4.17 ubuntu focal and jammy packages

28.10.2022 11:40, Kees van Vloten wrote:
> Hi Michael,
> 
> I just checked the repos you recently made available for Ubuntu. You have
separate repos for Ubuntu versions and also for Samba versions. This
> approach mimics the structure Louis has.
I don't really know about the structure of Louis repository - I never looked
there.
> I know the the Debian packages are available in the Debian repos, for
Buster mainly backports for a recent version. But Debian has a single repo with
> a single Samba version. Would it be possible to publish the Debian packages
(similar to Ubuntu) in a repo per Samba version on corpit.ru/mjt ?
It is not really like this on Debian.

The thing is that for Debian stable, we have 2 versions available: the one
shipped with bullseye (with most updates, at least the ones which didn't
require painful backporting), and the one available in the backports.

For bookworm, it will be bookworm release and bookworm-backports too (well,
hopefully anyway).  If bookworm were released earlier this year, it would
be 4.16 in bookworm and 4.17 in bpo, or something like that.

So that's two. It's possible to support buster-backports-sloppy as well,
and bullseye-backports-sloppy once bookworm will be out.

For debian unstable, there are again - for now - two version of samba
to choose from: it is unstable version, and it is experimental version.
Currently 4.17 is in experimental, and it is not available for debian
bullseye (current stable), -- this is because I'm not confident with
4.17 yet, myself. See the recent 4.17.2 bugfix release, - the CVE issue
with directory escape via symlinks. If it were not that, I'd move to
4.17 for unstable too, and stop providing 4.16 packages completely.

I don't want to publish two versions of samba for any of the
"supported"
distributions. Once I'm confident enough with 4.17, I will stop 4.16
packaging completely, and will focus on 4.17 entirely, for everything
including ubuntu and debian stable and debian unstable.

There's just no reason - in my opinion anyway - to provide packages for
older releases of samba.  I can branch the debian developer repository's
master branch in the point where we'll finally switch to 4.17, and it
should be easy to create subsequent releases of 4.16.x from there,
without touching any packaging stuff, just importing new upstream
versions and building new binaries. Especially once the dust settles
after the (minor) ubuntu changes I made in the packaging.

Also, Debian discourages using external repositories, and I understand
very well where this comes from, and support it.

My goal is to support single "good" current samba version for various
distributions. It is already happening for Debian, and it will happen
for Ubuntu as well. It is doable from a single line of development.

I provided 4.17 packages in there as experimental, to see if whole
thing actually works. It is the same as with experimental 4.17 for
Debian.  I hope to switch to 4.17 entirely in a near future.

Thanks,

/mjt

On 28-10-2022 10:57, Michael Tokarev wrote:
> 28.10.2022 11:40, Kees van Vloten wrote:
>> Hi Michael,
>>
>> I just checked the repos you recently made available for Ubuntu. You 
>> have separate repos for Ubuntu versions and also for Samba versions. 
>> This approach mimics the structure Louis has.
>
> I don't really know about the structure of Louis repository - I never 
> looked there.
Well, it is identical to the structure on corpit.ru/mjt
>
>> I know the the Debian packages are available in the Debian repos, for 
>> Buster mainly backports for a recent version. But Debian has a single 
>> repo with a single Samba version. Would it be possible to publish the 
>> Debian packages (similar to Ubuntu) in a repo per Samba version on 
>> corpit.ru/mjt ?
>
> It is not really like this on Debian.
>
> The thing is that for Debian stable, we have 2 versions available: the 
> one
> shipped with bullseye (with most updates, at least the ones which
didn't
> require painful backporting), and the one available in the backports.
>
> For bookworm, it will be bookworm release and bookworm-backports too 
> (well,
> hopefully anyway).? If bookworm were released earlier this year, it would
> be 4.16 in bookworm and 4.17 in bpo, or something like that.
Generally a next Debian release does not have usable packages for the 
current release, because of dependencies on newer package versions of 
almost everything including things like libc.
>
> So that's two. It's possible to support buster-backports-sloppy as
well,
> and bullseye-backports-sloppy once bookworm will be out.
>
> For debian unstable, there are again - for now - two version of samba
> to choose from: it is unstable version, and it is experimental version.
> Currently 4.17 is in experimental, and it is not available for debian
> bullseye (current stable), -- this is because I'm not confident with
> 4.17 yet, myself. See the recent 4.17.2 bugfix release, - the CVE issue
> with directory escape via symlinks. If it were not that, I'd move to
> 4.17 for unstable too, and stop providing 4.16 packages completely.
>
> I don't want to publish two versions of samba for any of the
"supported"
> distributions. Once I'm confident enough with 4.17, I will stop 4.16
> packaging completely, and will focus on 4.17 entirely, for everything
> including ubuntu and debian stable and debian unstable.
>
> There's just no reason - in my opinion anyway - to provide packages for
> older releases of samba.? I can branch the debian developer
repository's
> master branch in the point where we'll finally switch to 4.17, and it
> should be easy to create subsequent releases of 4.16.x from there,
> without touching any packaging stuff, just importing new upstream
> versions and building new binaries. Especially once the dust settles
> after the (minor) ubuntu changes I made in the packaging.
>
> Also, Debian discourages using external repositories, and I understand
> very well where this comes from, and support it.
>
> My goal is to support single "good" current samba version for
various
> distributions. It is already happening for Debian, and it will happen
> for Ubuntu as well. It is doable from a single line of development.
>
I understand this completely and generally I want as little custom repos 
as possible and let Debian manage the upgrade process. It is reliable, 
enhances security, saves me a lot of time, etc., etc. (lots of reasons :-) )

The notable exception is Samba (especially the domain controllers), I 
want to manage the upgrade moment of those. I do not want to upgrade all 
of them at the same time, I want to move the fsmo roles before upgrade 
and so on. In other words I want a very controlled manual process here, 
because a failure would lock out all users on all machines.
This works only if the repos have the packages of a version available 
until I decide to switch, the easiest way out is then to have a repo 
bullseye/samba-4.16 and bullseye/samba-4.17, etc.

Since you have already done the work for Ubuntu, it is probably not a 
lot of work to provide the same for Bullseye and as said it does provide 
a lot of value in the upgrade process of this critical piece of software.
> I provided 4.17 packages in there as experimental, to see if whole
> thing actually works. It is the same as with experimental 4.17 for
> Debian.? I hope to switch to 4.17 entirely in a near future.
>
> Thanks,
>
> /mjt