[Letsencrypt-devel] Bug#824928: letsencrypt.sh: move the default position of the domains file to /etc/letsencrypt.sh/

[Daniel Beyer]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/letsencrypt-devel/attachments/20160609/23c3b2b9/attachment.sig>