[Pkg-samba-maint] Bug#759008:

[Tobias Frost]

Am Mittwoch, den 06.05.2015, 14:20 +0000 schrieb Jelmer Vernooij:
> Hi Tobias,
> 
> On Wed, May 06, 2015 at 11:16:55AM +0200, Tobias Frost wrote:
> > Isn't the priorty our users? 
> > 
> > So what is most favourable for them?
> Most favourable and higher priority for our users is probably working on other bugs
> in Debian, that are not Hurd-specific...
> 
> I am generally sympathetic to porting efforts in Debian (see e.g.  #738669,
> #526069, #686931), but this patch is violating what tdb says it does in its
> package description and what its reverse dependencies count on. I don't think
> exposing users to software that is known broken is favourable either.

Please point me where it is known to break things.

> > IMHO: NOT having a TONS of software available not avialble due to this
> > bug is more severe than the bear some increased risk ("There be
> > dragons") that something breaks.
> When it breaks, it will be in a nonobvious way. It *will* break; as mentioned
> earlier, this patch is changing the very property for which tdb was written.
> Applications that use it tend to rely on this behaviour.  If you don't need multiple
> concurrent writers, gdbm is sufficient.
> 
> If this kind of compromise is reasonable, why does the Hurd not provide the
> byte-range locking API on top of the file-locking API itself? 
> 
> > So from my perspective, it is worth taking the risk.
> > Because only then bug reports will come in *if* anything breaks.
> > We'll only learn if we try.
> It's already broken. The Samba server side *will* break with this patch.
> Try running 'make test' in Samba's source on the Hurd with a tdb with this
> patch applied.

Just a question: How does tbd handles the situation when two
applications simultaneous wants to access (same area of) the database? 
How does it handle it one of the applications called tdb_lockall()
Does tbd not to need handle that to avoid dead locks? 
The API looks to me as locking-error information is available, and tbd
could error out if it detects such a problem. (

> > hurd is not a release arch, so even if that gives you bug reports, it
> > won't impact libtdb1.
> What about the maintainers of packages that depend on libtdb1? Should all Debian
> developers just ignore bugs reported by GNU/Hurd users, because these kinds of
> hacks are knowingly introduced?

As said, this is like "not having cake at all" or "having some cake at
least".

> 
> > Dear maintainer, please reconsider with the user's perspective I tried
> > to gave you above.
> Sorry. I think there are plenty of alternatives, ranging from hard to easy:
> 
>  1) Implement byte range locking on the Hurd
> 
>  2) Patch Samba to make using tdb for libsmbclient optional
> 
>  3) Patch Samba to use gdbm rather than tdb, and disabling the Samba server
>     code on GNU/Hurd.
> 
>  4) Add an alternative implementation of the TDB API and allow Samba to link
>     against that, disabling the server code on GNU/Hurd.
> 
>  5) Patch the various reverse dependencies of libsmbclient to build without
>     it on the hurd (AFAIK it's optional in all cases)

   6) Give it a try. In case warn loudly in Debian.NEWs, only installed
in hurd binary packages.

> Cheers,
> 
> Jelmer