On Sat, May 21, 2016 at 06:07:34PM +0000, Mattia Rizzolo wrote: > On Sat, May 21, 2016 at 07:14:05PM +0200, Daniel Beyer wrote: > > I opened a PR for upstream [1], based on the initial work you gave me. > > It might take a bit till upstream reacts to it, but I think chances are > > good it will be accepted. > > [1] https://github.com/lukas2511/letsencrypt.sh/pull/204 > > Great thanks! > > > I started working on updating our packaging in a new branch > > wip/dabe/domains.txt-in-etc.
In the meantime a new release happened, and our patch has been merged the commit right after the release one, useful. Anyway, I imported the new upstream release, and pulled your changes in debian/master. > > But I have the feeling, that mentioning the > > change in d/NEWS is not enough. > > I'd also keep in mind that this package is very young while considering > this. > > > So i came up with the following idea (not implemented, yet): > > During upgrade we check if a /var/lib/letsencrypt.sh/domains.txt exists > > and if so add an extra config file in /etc/letsencrypt.sh/conf.d/ to > > automatically reconfigure letsencrypt.sh back to the old location. With > > this we would not break things for our existing users. > > Do you have an other idea or opinion how to deal with this? > > That's a nice idea, even if I usually try to avoid having to deal with > maintainer scripts. > Anyway doing this also requires: > * checking that /etc/letsencrypt.sh/config.sh actually has DOMAINS_TXT > set to the new location (if the user modified it, dpkg won't overwrite > it with our new copy with our new conf) > * also adding a prerm to remove that file in case of purge > > > Also, I'd like to not keep that thing forever, e.g. drop this > transitional measure before stretch: I'm usually happier if my packages > don't have maintainer scripts. Are you willing to do this? I'm now running current debian/master, after having moved files around. With 0.2.0 there is also another incompatible change: the PRIVATE_KEY => ACCOUNT_KEY rename which actually bit me even if I was aware of it; do we want to provide a backward compatible thing and carry on some kind of deprecation procedure (like: using something like ACCOUNT_KEY=${ACCOUNT_KEY:-${PRIVATE_KEY}} somewhere and keeping it for a while) > > An other question is whether or not we should start shipping > > a /etc/letsencrypt.sh/domains.txt. I would prefer to do that, with a > > small header (lines containing '#' are ignored) outlining the purpose > > and the format of this domains.txt file. What do you think? > > Yes :) > Also notice the relative file in the new docs/ directory in the upstream > repo (I'd like to ship all that documentation when a new release will > happen). In the new package there is a /usr/share/doc/letsencrypt.sh/docs/domains_txt.md which imho contains everything needed. And if we provide an empty domains.txt, we should also first patch the script to return a useful message instead of saying nothing and just exit 0. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature