[Pkg-privacy-maintainers] Bug#858034: xul-ext-torbirdy: Please convert the debian/patches/socks_port* code changes to configuration

[intrigeri at debian.org]

Source: torbirdy
Version: 0.2.1-1
Severity: wishlist

Hi!

I've been working on improvements to the upstream code on Debian.
I usually do it this way:

1. I work on a topic branch forked from upstream's master branch.
   And I commit my work there.
2. I switch to the Debian packaging branch with `git checkout'.
3. I run `gbp pq rebase' to switch to a patch-queue/* branch.
4. I merge my topic branch.
5. I run `gbp pq export' to export all changes to debian/patches/.

This usually works fine, but I've found step #4 to be very painful
recently while working on code chunks that are close to (or exactly
the same as) the ones we patch via debian/patches/socks_port*.

This experience prompted me into looking at these patches.
My conclusion is that _code_ changes should really not be required to
modify the default SOCKS port (besides, patching the code in three
different places to apply what's essentially one single change felt
wrong, but this is not really what this report is about).

I don't know if it's a problem with the upstream code not offering
vendors like Debian the flexibility we need to adjust the defaults,
while allowing the user to supersede them as needed. Or if it's
a problem of us not using the available facilities to set our
vendor-specific defaults. If the former, then I'm happy to let
upstream know about our needs myself. If the latter, then well, this
wishlist bug should be enough to document what could be done to
improve the situation :)

FWIW, in Tails we ship a /etc/xul-ext/torbirdy.js file, that contains
this line:

  pref("extensions.torbirdy.custom.network.proxy.socks_port", 9061);

It's enough to set our vendor-specific settings, which is a good
starting point. But I do not know if it allows the user to supersede
them if needed (which is needed in Debian, although not in Tails).

Cheers,
-- 
intrigeri