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

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

28.10.2022 12:30, Kees van Vloten wrote:
..
> 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.
I meant the bpo mechanism, it works fairy well.

...
> 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.
Heh. I do build for Debian *first*, *before* building stuff for Ubuntu :)
Actually I want to upload to Debian first, before building/uploading
stuff to the ubuntu repository.

But having exactly the same version of a package both in official
Debian repository and in external Debian repository makes apt a
bit frustrated (and in Debian the packages will be rebuilt, so
binaries will be different, - at least the timestamps will be
new). And I don't want to touch version number without actual
source changes.



Speaking of your delayed way to upgrade, - you can stick to a
particular Debian version of whole system and install bpo version
of samba on it, or you can install bpo version of samba before
eg bullseye->bookworm upgrade (so samba packages will be the
same after system upgrade), and so on, - there are numerous
options.

Thanks,

/mjt