Remove and replace Samba Debian packaging tree ?

Christian Perrier bubulle at
Wed Sep 12 16:46:17 GMT 2007

Quoting Dan Shearer (dan at
> Jerry,
> With your current load do you still see you can take on
> packaging/Debian? You suggested swapping Fedora reponsibilities with
> Simo:
> I just pulled 3.0.26 from Debian sid and built it. Christian and Steve
> have done a fine job so as a start maybe you could just remove
> everything under packaging/Debian and replace it with what they have.

Hmm, thanks a lot for the kind words (we should however not forget
Eloy Paris who maintained samba alone for years, then Noèl Köthe and
Peter Eisentraut who are part of the current Debian packaging team in
addition to Steve Langasek and myself).

About replacing the current packaging/Debian by our work, I advise
against doing this *blindly*, particularly for our patches..

This should certainly be a goal for both parts (Samba team and Debian
maintainers). However, we have some changes, in debian/patches, which
introduce changes with regard of the software behaviour.

The most proeminent one is the fhs.patch we have.

Its goal is introducing new possible directories locations, namely
state_path, data_path and cache_path. QUoting the patch comments:

cache_path contains discardable cache data (/var/cache/samba):
          browse.dat, printers.tbd, <printer>.tdb
state_path contains non discardable state data (/var/lib/samba):
          all TDB files that may need to be backed up
data_path contains static shared data (/usr/share/samba):
          codepage stuff

Most of these go in lib_path in default samba installs with unpatched

This fhs.patch also changes the default for PID and lock files
(lock_path) which is /var/run/samba instead of /var/lib/samba

As you see, this changes the files locations and, therefore, may
introduce inaccuracies or even errors in available documentation.

Our (Debian team) goal is certainly to have this included in upstream
as it would save us a lot of work for each new release, to identifify
possible new places for us to patch.

However, we are aware this is an important change that could affect
the whole Samba team habits and we want to be careful and precise
discussing that change.

I was indeed about to split that patch in two parts:
- one introducing the new directory variables
- one making the defaults for these values to be the ones we want in

The first one could then be integrated upstream and keeping default
values that do not change the software behaviour while the latter
could remain Debian-specific.

So, as you see, at least this patch, and maybe others, need
investigation to see whether they're applied in packages provided by
the Samba team (which should, by definition, use source code that's as
close as possible of the one provided in released tarballs).

I hope these explanations are clear...:)

More information about the samba-technical mailing list