All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Laszlo Boszormenyi (GCS)" <gcs@debian.hu>
To: Sage Weil <sage@inktank.com>
Cc: Dan Mick <dan.mick@inktank.com>,
	Mark Nelson <mark.nelson@inktank.com>,
	ceph-devel@vger.kernel.org, james.page@ubuntu.com
Subject: Re: deb/rpm package purge
Date: Wed, 20 Mar 2013 23:23:35 +0000	[thread overview]
Message-ID: <1363821815.12547.97.camel@julia> (raw)
In-Reply-To: <alpine.DEB.2.00.1303200545140.11428@cobra.newdream.net>

On Wed, 2013-03-20 at 05:48 -0700, Sage Weil wrote:
> On Wed, 20 Mar 2013, Laszlo Boszormenyi (GCS) wrote:
> > On Tue, 2013-03-19 at 15:59 -0700, Sage Weil wrote:
> > > As a point of comparison, mysql removes the config files but not 
> > > /var/lib/mysql.
> > > The question is, is that okay/typical/desireable/recommended/a bad idea?
 I should have asked this sooner. Do you know _any_ program that removes
your favorite music collection, your family photos or your business
emails when you do uninstall it?
I suspect that your question was theoretical instead.

On Wed, 2013-03-20 at 09:48 -0500, Mark Nelson wrote:
On 03/20/2013 07:48 AM, Sage Weil wrote:
> It's not as important given that it won't outright destroy the cluster, 
> but perhaps we should also leave /etc/ceph untouched on purge if a 
> ceph.conf file has been placed in it (since that also was not installed 
> by the package, but rather by a user?).  I figure we should probably try 
> to get it right now.  The message about the directory not being empty 
> sounds good.
 Sure, personal user data must be kept. If it's a big amount of data and
left under a non-standard location (ie, not under his/her $HOME) then
s/he should be informed where those files are located on purge.

> My thought here is:
> - remove anything created by the packages in /var/lib/ceph that has been 
> untouched since package installation.
> - remove /var/lib/ceph if it has been untouched
 Please note that you have to store some kind of checksum for the files
then. Probably md5sum is enough.

> - remove /etc/ceph if it has been untouched
 This is an other case. dpkg itself handle package files here, called
conffiles. I should check the method (md5sum and/or sha1 variants) used
for the checksum on these files. On upgrade it's used not to overwrite
local changes by the user. It may worth to read a bit more about it[1]
from Raphaël Hertzog. He is the co-author of Debian Administrator's
handbook[2] BTW.
 On purge dpkg will remove the package conffiles no matter what. It
won't check if those were changed or not. You may not mark the files
under /etc as conffiles, but then you'll lose the mentioned
merge logic on upgrades; dpkg will just overwrite those.
 In short, files under /var/lib/ceph are the only candidates for
in-package checksumming. How many files under there that essential for
the packages?

Laszlo/GCS
[1] http://raphaelhertzog.com/2010/09/21/debian-conffile-configuration-file-managed-by-dpkg/
[2] http://debian-handbook.info/

--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2013-03-20 23:23 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-19 19:48 deb/rpm package purge Sage Weil
2013-03-19 19:59 ` Greg Farnum
2013-03-19 20:05 ` Mark Nelson
2013-03-19 20:46   ` Dan Mick
2013-03-19 20:51     ` Sage Weil
2013-03-19 22:27       ` Laszlo Boszormenyi (GCS)
2013-03-19 22:29         ` Sage Weil
2013-03-19 22:51           ` Laszlo Boszormenyi (GCS)
2013-03-19 22:59             ` Sage Weil
2013-03-20  6:29               ` Laszlo Boszormenyi (GCS)
2013-03-20 12:48                 ` Sage Weil
2013-03-20 14:48                   ` Mark Nelson
2013-03-20 17:27                     ` James Page
2013-03-20 23:23                   ` Laszlo Boszormenyi (GCS) [this message]
2013-03-21  1:08                     ` Dan Mick
2013-03-19 23:01             ` Mark Nelson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1363821815.12547.97.camel@julia \
    --to=gcs@debian.hu \
    --cc=ceph-devel@vger.kernel.org \
    --cc=dan.mick@inktank.com \
    --cc=james.page@ubuntu.com \
    --cc=mark.nelson@inktank.com \
    --cc=sage@inktank.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.