[DRE-maint] Bug#819854: [Letsencrypt-devel] Bug#819854: wouldn't Recommends: be better?

[Pirate Praveen]

[adding dbconfig maintainer]

On Monday 04 April 2016 01:39 PM, Axel Beckert wrote:
> dbconfig is something Debian-specific and used by _many_ packages and
> there are probably very little users who don't want that and are
> capable of managing this.
> 
> The fact that gitlab uses letsencrypt seems something that upstream
> has decided on. And so far, gitlab is the only package which depends
> on letsencrypt. Additionally, letsencrypt can be considered
> controversial.

No, upstream has not decided on letsencrypt. gitlab maintainers decided
to use letsencrypt. The number of packages depending on letsencrypt is
small because it is very new. We are already working on adding
letsencrypt to diaspora-common too. Any web based software would want to
make it easy to configure ssl and letsencrypt is the perfect solution
for that.

> And actually, I don't know why there is a dbconfig-no-thanks package
> at all. My guess is that just skipping dbcommon doesn't work and the
> file /usr/share/dbconfig-common/internal/dbc-no-thanks is required.
> Which sounds like a bug in its design.

You want a db to be configured for the app to work.

> Anyway, the general idea of …-no-thanks packages still looks fishy to
> me and I surely would avoid to introduce more such packages instead of
> using Recommends — which is clearly meant for such situations.

Paul may be able to give their rationale for using dbconfig-no-thanks

>> If it is just in Recommends, you have to disable recommends for each
>> package that uses letsencrypt.
> 
> Why doesn't "apt-get install gitlab letsencrypt-" suffice? (Same for
> aptitude. Actually aptitude had that feature earlier. And
> interactively that situation is like cake in aptitude's TUI.)

It is an additional step and not intuitive. I want things to work well
by default and dig further only when it is required.

>> I want this as depends but allow people to opt out.
>> dbconfig-no-thanks was a perfect solution
> 
> It looks to me like a very hacky solution which works around the
> system and should be avoided whereever possible.
> 
>> This is already done in gitlab.
> 
> Then everything should be fine already.
> 
>> If you don't think this is a good idea, you may close this bug.
> 
> I've Cc'ed letsencrypt-devel at lists.alioth.debian.org to get another
> opinion on that, but I doubt that this will change the situation.

Lets see what they think.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-ruby-extras-maintainers/attachments/20160404/eff1c1b0/attachment.sig>