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

[Paul Gevers]

Hi Pirate,

[Dropping this from the letsencrypt bug, as there is nothing about
letsencrypt in this e-mail.]

On 04-04-16 10:18, Pirate Praveen wrote:
> On Monday 04 April 2016 01:39 PM, Axel Beckert wrote:
>> 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.

<irony> Axel, Thanks for bringing this up when I asked the question on
debian-devel.¹ (see the line about: "Please speak up")</irony>

No dbc-no-thanks is only needed for dependency resolving. The problem
dbconfig-common was having was twofold. 1) multiple command line clients
are required by dbconfig depending on which backend was needed. Depeding
on all the packages providing those command line clients pulls in loads
of packages that are not needed for whatever you wanted to do. Therefor,
I added dbconfig-<dbtype> packages, such that you (as admin or package
maintainer) can properly tell which backend you want. For admins that
don't want the dbconfig-common support, dbconfig-no-thanks is the way to
tell that at the system level, because 2) even though dbconfig-common
handles loads of cases, there are cases where it doesn't work very well
from the admin perspective. Remember, loads of database run on remote
systems and the Debian dependency system doesn't support that use case
at all. So I believe this is the best I could do.

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

Indeed.

>> 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

See above. And to additionally add to the remark of Axel, the package
maintainer should not need to have loads of code to handle the case
where dbconfig is not installed while you want a db. By having the
Depends on dbconfig, that can be handled internally.

I invite you to join my BOF at Debconf² to discuss this in more detail.

>>> 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.

Of course I am open to other options. But discussing this last year at
Debconf, this was actually the only sane thing that came out over the
previous implementation (which people weren't really happy with)...

Paul

¹ https://lists.debian.org/debian-devel/2015/12/msg00044.html
² https://debconf16.debconf.org/talks/1/ (looks like you need to be
logged in to see this)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/letsencrypt-devel/attachments/20160404/e1155fd9/attachment.sig>