[Samba] Samba 3.2.0 in Debian "lenny"

Christian Perrier bubulle at debian.org
Wed Aug 6 11:17:39 GMT 2008

Quoting Ryan Novosielski (novosirj at umdnj.edu):

> > Only security patches.
> Is that right? Does that mean that if something is completely broken, it
> will stay that way for the life of the Debian release?

s/Only security patches/Only release critical issues

So, "something completely broken" would probably fit in the definition
of a grave bug which is "makes the package in question unusable or
mostly so, or causes data loss"

There are 3 bug severities that are release critical in the Debian

          makes unrelated software on the system (or the whole system)
          break, or causes serious data loss, or introduces a security
          hole on systems where you install the package.

          makes the package in question unusable or mostly so, or causes
          data loss, or introduces a security hole allowing access to the
          accounts of users who use the package.

          is a severe violation of Debian policy (roughly, it violates a
          "must" or "required" directive), or, in the package maintainer's
          or release manager's opinion, makes the package unsuitable for

All those 3 issues may justify an update in the stable
release. However, maintainers have to do this by backporting patches,
*not* by only upgrading software....which sometimes makes the process
fairly difficult.

Such issues motivating non security-related fixed to be backported
happened *very* rarely in the past with Samba. We still have tons of
uers happily running 3.0.24 with Debian Etch and even probably a lot
running 3.0.14a with Debian sarge (but those are no longer supported
wrt security updates). 

It may become more problematic with software where security and
release critical fixes are very hard to backport and where the
upstream answer is "just upgrade to the last version" (Mozilla comes
to mind). This never happened with Samba as the Samba Team has always
been very careful to provide useful information to "vendors" as they
now that not everybody can always proide or use the very latest version.

> > That, indeed, is one of the reasons for which we should continue the
> > effort started a few months ago to bring back some .deb packages on
> > samba.org and have these packages to be as close as possible of
> > packages provided in Debian (and Ubuntu) itself so that users can
> > choose to either stick with what's provided with their distro and to
> > follow bleeding edge versions.
> Agreed. Again, though (and this question is rhetorical), what can be
> done in a situation where you know that the current release is not quite
> at the right level of quality, but the previous one will be unsupported
> by the end of your release cycle? I don't have an answer for that.
> Ubuntu has the luxury of being able to go with the bleeding edge because
> its users don't necessarily need the stability that Debian provides.
> Making it the user's option to go out and get newer packages from the
> 3rd party itself is a nice option, but when the package shipped with the
> distribution has a major problem, it makes one wonder why even ship one
> at all? Tricky.

If the problem is identified as major, then we'll do our best to fix

But, well, we're volunteers, you know. None of us is paid for the work
on Samba Debian packages, so the work that's done essentially depends
on the resources we have (hint: volunteers welcome to help maintaining
Debian packages and, no, that does not require to be an official
Debian Developer).

More information about the samba mailing list