Hi Mattia, sorry for the very late response.
On Thu, 2016-06-02 at 11:14 +0000, Mattia Rizzolo wrote: > 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. > > (...) > > In the meantime a new release happened, and our patch has been merged > the commit right after the release one, useful. That's bad luck. Let's stick with the patch for now. > Anyway, I imported the new upstream release, and pulled your changes in > debian/master. Okay, thanks. > > > 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. That's true, hence I think it's worth the extra work - at least for the jessie-backports version. > > > So i came up with the following idea (not implemented, yet): > > > (...) > > > 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 Thanks for the input, I'll keep this in mind. > > 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. I fully agree. Let's keep it some time and drop it out before the stretch freeze. > Are you willing to do this? > I'm now running current debian/master, after having moved files around. Definitely, I work on this today and tomorrow. > 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) It would be a nice service for our users (just like the domains.txt stuff). So I would say: Yes and drop it before the stretch freeze. > > > An other question is whether or not we should start shipping > > > a /etc/letsencrypt.sh/domains.txt. (...) What do you think? > > > > Yes :) Okay, let's ship it. > > 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). I saw you already took care about the docs, thanks. > In the new package there is a > /usr/share/doc/letsencrypt.sh/docs/domains_txt.md which imho contains > everything needed. Great, so we can simply point to it in /etc/letsencrypt.sh/domains.txt. > 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. That's true. It might be worth to forward this upstream (once implemented). I'll get back to you as soon I have implemented something useful here. Greetings Daniel
signature.asc
Description: This is a digitally signed message part