Purging MRTG removes data from /var/www/mrtg

A purge is designed to remove *all* folders and data which have been created by that package.
This is expected functionality, so I am closing this report. Feel free to continue to submit reports.

On Nov 13, 2007 3:37 PM, Johnathon <email address hidden> wrote:

> A purge is designed to remove *all* folders and data which have been
> created by that package.
> This is expected functionality, so I am closing this report. Feel free to
> continue to submit reports.
>

The problem is that is also removes data *not* created by that package.

--
Paul Elliott (omahn)
Systems Engineer, Option-C Services
<email address hidden>

Our real world example is this. We migrated a machine from Redhat to Ubuntu and installed the mrtg package. We then copied over all our MRTG data from the old server to /var/www/mrtg. Later in the day we had an issue with perl and so we decided to purge the perl packages to start afresh. MRTG was included in this purge and it therefore removed all our data we had copied across. I think this is poor practice, if the package is to continue to remove the data it should at least warn the user. (As in a previous comment, MySQL server will query if the user wants to remove the data during a purge operation, this is ideal.)

----- "Omahn" <email address hidden> wrote:
> On Nov 13, 2007 3:37 PM, Johnathon <email address hidden> wrote:
>
> > A purge is designed to remove *all* folders and data which have
> been
> > created by that package.
> > This is expected functionality, so I am closing this report. Feel
> free to
> > continue to submit reports.
> >
>
> The problem is that is also removes data *not* created by that
> package.

Your data is in a folder which has been created by the package. purge removes all folders created by the package on install - that is it's function, to literally purge the pacakge's existance from your computer. If you don't want this, use remove, not purge.

--
Blog: kirrus.co.uk
Work: encryptec.net
RPGs:
Captain Senaris Vlenn, CO, USS Sarek
Lt Aieron Peters, XO DS5

On Nov 13, 2007 4:04 PM, Johnathon <email address hidden> wrote:

> ----- "Omahn" <email address hidden> wrote:
> > On Nov 13, 2007 3:37 PM, Johnathon <email address hidden> wrote:
> Your data is in a folder which has been created by the package. purge
> removes all folders created by the package on install - that is it's
> function, to literally purge the pacakge's existance from your computer.
> If you don't want this, use remove, not purge.
>

But this contravenes the Debian packaging policy, if Ubuntu has a different
policy could you point me in the right direction?

Thanks.

--
Paul Elliott (omahn)
Systems Engineer, Option-C Services
<email address hidden>

----- "Omahn" <email address hidden> wrote:
> On Nov 13, 2007 4:04 PM, Johnathon <email address hidden> wrote:
>
> > ----- "Omahn" <email address hidden> wrote:
> > > On Nov 13, 2007 3:37 PM, Johnathon <email address hidden> wrote:
> > Your data is in a folder which has been created by the package.
> purge
> > removes all folders created by the package on install - that is
> it's
> > function, to literally purge the pacakge's existance from your
> computer.
> > If you don't want this, use remove, not purge.
> >
>
>
> But this contravenes the Debian packaging policy, if Ubuntu has a
> different
> policy could you point me in the right direction?
>
> Thanks.
>
Hi,

I am just a first-line triager, so I may have got it wrong. But technically speaking, it is extreemly difficult for a seperate program (packaging system) to learn whether a folder is content or configuration. In this case, the packaging system treats it as configuration, as the files & folder in which they are contained have been generated by the program.

Because of the way that Ubuntu is setup, if this is the case here, you'll likely experience the same effect in Debian.
I can reset the bug to new status, and leave it for another triager to take a look if you wish, but as far as I am aware this is not a bug.

--
Blog: kirrus.co.uk
Work: encryptec.net
RPGs:
Captain Senaris Vlenn, CO, USS Sarek
Lt Aieron Peters, XO DS5

On Nov 13, 2007 5:41 PM, Johnathon <email address hidden> wrote:

> I am just a first-line triager, so I may have got it wrong. But
> technically speaking, it is extreemly difficult for a seperate program
> (packaging system) to learn whether a folder is content or
> configuration. In this case, the packaging system treats it as
> configuration, as the files & folder in which they are contained have
> been generated by the program.
>

The behaviour I've seen in other packages is to remove all the files
installed in the relevant folder (3 in this case) and then remove the
folder, but only if it's empty. If the user has put anything else in the
folder after the package was installed then the folder is left.

> Because of the way that Ubuntu is setup, if this is the case here, you'll
> likely experience the same effect in Debian.
> I can reset the bug to new status, and leave it for another triager to
> take a look if you wish, but as far as I am aware this is not a bug.
>

Please do reset to new. Unfortunately it's little packaging issues like this
that prevent organisations such as the one I work at from moving from
systems such as Solaris to Linux.

Thanks.

--
Paul Elliott (omahn)
Systems Engineer, Option-C Services
<email address hidden>

I found a good example of how I would expect the mrtg package to behave, in this instance it's the openvpn package. I had the package already installed so I just added another file to the conf directory to emulate the presence of user data. I then purged the package. You can see at the end of the listing that the user data is left untouched and the directory intact.

elliotp@lenny:/etc/openvpn$ ls
update-resolv-conf
elliotp@lenny:/etc/openvpn$ sudo touch testing
[sudo] password for elliotp:
elliotp@lenny:/etc/openvpn$ cd ..
elliotp@lenny:/etc$ sudo apt-get --purge remove openvpn
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED
  network-manager-openvpn* openvpn*
0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.
Need to get 0B of archives.
After unpacking 1581kB disk space will be freed.
Do you want to continue [Y/n]?
(Reading database ... 132272 files and directories currently installed.)
Removing network-manager-openvpn ...
Purging configuration files for network-manager-openvpn ...
Removing openvpn ...
Stopping virtual private network daemon:.
Purging configuration files for openvpn ...
dpkg - warning: while removing openvpn, directory `/etc/openvpn' not empty so not removed.
elliotp@lenny:/etc$

I have duplicated this behaviour here; confirming bug report.

Packaging / Bitesize bug, Assigning to motu.

I'll take a stab

This seems to work fine:

laney@egg:~$ sudo touch /var/www/mrtg/should_block_delete
laney@egg:~$ sudo apt-get remove --purge mrtg
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED
  mrtg*
0 upgraded, 0 newly installed, 1 to remove and 5 not upgraded.
2 not fully installed or removed.
After this operation, 1339kB disk space will be freed.
Do you want to continue [Y/n]? y
(Reading database ... 137857 files and directories currently installed.)
Removing mrtg ...
Purging configuration files for mrtg ...
dpkg - warning: while removing mrtg, directory `/var/www/mrtg' not empty so not removed.
dpkg - warning: while removing mrtg, directory `/var/www' not empty so not removed.

You may want to use debconf to ask users if they want to purge /var/www/mrtg and all files in.

Using debconf for this might be an overkill though, this will for instance break translations and since the Debian developer do not seem to be very active for this package I don't think this is a good idea.
There is a new upstream which seems quite active (2.16.1 has just been released) so I think it could make sense to patch this as proposed and wait for Debian to re-activate to implement this properly through debconf.
In this respect it would also be good to issue a bug in the Debian BTS to alert them about this issue as well as to the fact that there is a new upstream release.

I will submit a bug upstream shortly.

OK, I've added a debconf template as you requested. Both patches are now here for someone to decide which is the way to go ;) The meat is at the bottom - all of the other stuff was generated by debconf-updatepo.

Ok, let's leave debconf implementation to Debian maintainer for now.

This bug was fixed in the package mrtg - 2.14.7-2ubuntu3

---------------
mrtg (2.14.7-2ubuntu3) hardy; urgency=low

  * Don't unconditionally remove /var/www/mrtg when purging.
    Changed files: debian/postrm (LP: #162426)

 -- Iain Lane <email address hidden> Tue, 19 Feb 2008 22:05:03 +0000