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.
> 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.
> 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?
> 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)
Cheers,
Jelmer
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
