[debian-mysql] Groping for a roadmap in the dark
Clint Byrum
clint at ubuntu.com
Mon Jun 11 16:55:27 UTC 2012
Excerpts from Olaf van der Spek's message of 2012-06-11 07:42:19 -0700:
> On Fri, Jun 8, 2012 at 1:55 PM, Nicholas Bamber <nicholas at periapt.co.uk> wrote:
> >> Piuparts is an awesome assessment of where we stand w.r.t. policy. Its
> >> true,
> >> we are not automatically purging data if the question about whether or not
> >> to remove /var/lib/mysql/* is left to defaults.
> >>
> >> I'd entertain making mysql-server-5.5/postrm_remove_databases default to
> >> true
> >> rather than false, as long as it is noted in NEWS, and the question is
> >> given
> >> a high priority. As I understand it, this would solve the issue entirely.
> >
> >
> > It seems we are in agreement. Basically I think we need to do everything we
> > can to alert the user to this change. This will include having the change in
> > either experimental or unstable for most of wheezy+1.
> >
> > Olaf however will doubtless disagree. I would like to make sure he has an
> > opportunity to make his case. There is a while before I get to piuparts on
> > the roadmap.
>
> Certainly. Do we know what Postgres does yet? Do we know if a piuparts
> exception is possible?
>
> Users don't (like to) read docs. They might not read NEWS, for
> whatever reason. Users shouldn't be bothered.
> AFAIK purge doesn't delete data, it deletes conf. Users expect the
> same, otherwise you wouldn't have to bother with NEWS and questions.
>
I hit reply intending to say "Oh no its data too". But it turns out, the
relevant man pages are somewhat silent on data:
man apt-get:
purge
purge is identical to remove except that packages are removed
and purged (any configuration files are deleted too).
man dpkg:
purge The package is selected to be purged (i.e. we want to
remove everything from system directories, even
configuration files).
-r, --remove, -P, --purge package...|-a|--pending
Remove an installed package. -r or --remove remove
everything except conffiles. This may avoid having
to reconfigure the package if it is reinstalled
later. (Conffiles are configuration files that are listed in
the DEBIAN/conffiles control file). -P or --purge removes
everything, including conffiles.
It seems pretty clear to me that what piuparts expects is in direct
conflict with these man pages. I haven't been able to find any relevant
bug reports, though 535577 seems as good as any other place to discuss
this confusing bit.
Anyway, at this point I'm comfortable with letting go of any problems
that piuparts reports about /var/lib. Nicholas, if you just want piuparts
testing for your massive changes, I'd suggest that you approach the
piuparts maintainer(s) about the above inconsistencies before changing
the default behaviors.
> It's like first setting a trap and then putting up a warning sign.
>
> Why are we trying so hard to avoid a piuparts exception?
>
> > So I throw the question back to you. How would you respond to #511438?
>
> How big is the test and other optional stuff? If it's significant it
> seems reasonable to split it.
>
> >>> 6.) Config modularity. The modern way would
> >>> be for mysql-config to store a skeleton /etc/mysql/my.cnf and something
> >>> to keep
> >>> /etc/mysql/conf.d alive. However we will have to keep just enough
> >>> in /etc/mysql/my.cnf not to break the existing 5.5. Each of the packages
> >>> would own its appropriate config fragment below /etc/mysql/conf.d .
>
> Maybe we should remove documentation (and commented entries) from conf
> files. It's easy to include a link to the documentation and a clean
> conf file is easier to read.
Huh? I don't understand this suggestion at all. Comments and docs are
extremely useful for new users, and you probably don't even see them as
an advanced user.
Anyway, Nicholas was talking more about the layout of the config file,
not the content.
Everybody prefers the .d style of config file management. Just have a
file for each section that is currently in my.cnf, and a single line
file that includes the dir.
More information about the pkg-mysql-maint
mailing list