Re: Review request for dbconfig-common with new packages
Paul Gevers wrote:
>> Would there be any point explicitly mentioning "or MariaDB" just once,
>> like this?
>
> Ooo, yeah, good catch, maybe also in the description?
The synopsis/short description, you mean? Possibly, unless people see
MariaDB as a subcategory of MySQL.
>>> Description: prevents database management by dbconfig-common
>>
>> The DevRef recommendation is to phrase that more nounily - something
>> like
>> Description: dummy package to prevent database management by dbconfig-common
>
> I don't like the word dummy in this context. Most of the time dummy
> packages can be removed again, that is not the case here. If we go for
> dummy here, we could also use that word in the other cases (as the use
> is very similar).
You mean the other packages that exist only to provide dependencies?
I was thinking this was a bit more dummylike on the grounds that it
does less, but yes, there's a risk that using it might lead to
confusion.
(The ones that can be removed tend to be called transition packages,
but this isn't really a dummy package in any of the normal senses.)
>> Or we might be able to shorten that... maybe even to:
>>
>> Description: dbconfig-common bypass
>
> dbconfig-no-thanks <is a> dbconfig-common bypass... yes, I like that
> better than the dummy. Or:
> Description: bypass for dbconfig-common
> or use the word "block", as in ad-block?
Maybe; but the things named AdBlock(Plus) are "ad blockers", and the
word makes me think of those packages people were coming up with last
year that did nothing but conflict violently with systemd. Still, the
verb could be useful...
>>> This package prevents the dbconfig-common framework from managing database for
>>> packages that require a working database and that rely on dbconfig-common to
>>> handle setup and maintenance. This package is intended for systems where the
>>> system administrator requires or desires full control of the database or where
>>> dbconfig-common makes the wrong choises. Typically this will leave the
>>> depending packages non-functional until the required actions are performed.
>>
>> That first sentence is a bit long and awkward; I think for a start it
>> needs to be "managing ^a^ database". But a slight reshuffle lets me
>> compress it a bit.
>
> Full ack, except for the ^a^. In some places I like the plural version
> better.
Surely dbconfig-common only ever pulls in and manages one database for
any one package?
>> Typo: s/choises/choices/
>>
>> Add the word "manual"?
>>
>> When a package normally relies on the dbconfig-common framework to set up
>> and maintain a database, installing this dummy package instead will prevent
>> dbconfig-common from managing a database. It is intended for systems where
>> the system administrator requires or desires full control of the database or
>> where dbconfig-common makes the wrong choices. Typically this will leave the
>> depending packages non-functional until the required manual actions are
>> performed.
>>
>> Or perhaps:
>>
>> When a package relies on the dbconfig-common framework to set up and
>> maintain a database, installing dbconfig-no-thanks instead of one of the
>> dbconfig-<database> choices will prevent it from managing a database. This
>> is intended for systems where the system administrator desires or requires
>> full control of the database or where dbconfig-common makes bad choices.
>> Typically this will leave the depending packages non-functional until the
>> required manual actions are performed.
I hadn't noticed that my attempt to compress it actually made it
longer!
> I like the second version better, but have small doubt regarding
> dbconfig-<database>. First, elsewhere I believe I mention <database
> type>, and second, is it clear in this context and with this notation
> what readers should read here? Maybe: "... instead of one of the
> database specific dbconfig packages ..."
Yes, that works. You should probably add a hyphen. Making another
attempt to trim it down:
If a package relies on the dbconfig-common framework for database setup and
maintenance, installing dbconfig-no-thanks instead of one of dbconfig's
database-specific packages will block this function. It is intended for cases
where the system administrator desires or requires full control of the
database or where dbconfig-common makes bad choices, and typically leaves
the depending packages non-functional until manually configured.
Well, that's a *bit* shorter...
>>> _Description: Database type to be used by ${pkg}:
>>> The ${pkg} package can be configured to use one of several database types.
>>> Below, you will be presented with the available choices.
>>> .
>>> It is possible that the package supports more database types than shown. In
>>> that case the corresponding dbconfig-<database type> packages are not installed
>>> so the options are removed for now. If you know that you want the package to use
>>
>> It took me a while to work out that this was saying:
>>
>> If other database types are supported but not shown here, the reason for their
>> omission is that the corresponding dbconfig-<database type> packages are not
>> installed. If you know that you want the package to use [...]
>
> ... are supported by ${pkg} but not shown ...
Yes, okay.
>> It seems odd to say "the required DB-type" when I've got a free
>> choice. Maybe this should be:
>>
>> If other database types are supported but not shown here, the reason for their
^by ${pkg}
>> omission is that the corresponding dbconfig-<database type> packages are not
>> installed. If you know that you want the package to use another supported
>> database type, your best option is to back out of the dbconfig-common questions
>> and opt out of dbconfig-common assistance for this package for now. Install
>> your preferred dbconfig-<database type> option from the list in the package
>> dependencies, and then "dpkg-reconfigure ${pkg}" to select it.
>
> Paul
> PS after the next round I will update what we have so far and attach it
> to my next mail.
Okay.
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Reply to: