I couldn't find this in the guidelines and I'm looking for clarification.
When a package generates data as a consequence of it's runtime operation should the package data also be removed along with the package files when the package is uninstalled (i.e. rpm -e)?
Issues:
* It may be a user expectation that removing a package removes all the files associated with the package even if they are not package files (listed in %files). Most people remove packages because they don't want or need the package any more and don't want cruft left behind, they want a clean uninstall which recovers the maximum disk space possible without "orphans"
* Generated data may have value after the package is removed, for some users it might be an unpleasant experience to discover after removing a package the data files were wiped out too.
* It's not possible to query the user at uninstall time as to the disposition of data files because the uninstall (like install's) may be scripted.
My inclination is the packaging guidelines should encourage the removal of data files generated by the package when the package is removed.
Comments?
John Dennis jdennis@redhat.com writes:
My inclination is the packaging guidelines should encourage the removal of data files generated by the package when the package is removed.
In the case of the database packages the longstanding policy is the opposite. I can see encouraging packagers to remove orphaned preference or configuration files, but not potentially-high-value user data.
regards, tom lane
On 11/18/2009 11:44 AM, Tom Lane wrote:
John Dennisjdennis@redhat.com writes:
My inclination is the packaging guidelines should encourage the removal of data files generated by the package when the package is removed.
In the case of the database packages the longstanding policy is the opposite. I can see encouraging packagers to remove orphaned preference or configuration files, but not potentially-high-value user data.
whole-heartedly agree, it's something that really is best managed on a case-by-case basis (probably one reason why it's not in the guidelines... yet).
-- Rex
On 11/18/2009 12:49 PM, Rex Dieter wrote:
On 11/18/2009 11:44 AM, Tom Lane wrote:
John Dennisjdennis@redhat.com writes:
My inclination is the packaging guidelines should encourage the removal of data files generated by the package when the package is removed.
In the case of the database packages the longstanding policy is the opposite. I can see encouraging packagers to remove orphaned preference or configuration files, but not potentially-high-value user data.
whole-heartedly agree, it's something that really is best managed on a case-by-case basis (probably one reason why it's not in the guidelines... yet).
Both Rex and Tom immediately converged on exactly the issue I was thinking about, database style packages.
I can see a strong argument for preserving the content after package removal, if this is the precedence I think the guidelines should at least state this, but permit per-package interpretation as opposed to enforcing a mandate.
However I can also see a strong argument for wanting a package to clean up after itself so that a user does not have to find every place a package has written files, which in many instances is not so easy to discern. The principle of least surprise might suggest removing a package removes everything associated with the package.
On 11/18/2009 11:34 AM, John Dennis wrote:
I couldn't find this in the guidelines and I'm looking for clarification.
When a package generates data as a consequence of it's runtime operation should the package data also be removed along with the package files when the package is uninstalled (i.e. rpm -e)?
Issues:
- It may be a user expectation that removing a package removes all the
files associated with the package even if they are not package files (listed in %files). Most people remove packages because they don't want or need the package any more and don't want cruft left behind, they want a clean uninstall which recovers the maximum disk space possible without "orphans"
- Generated data may have value after the package is removed, for some
users it might be an unpleasant experience to discover after removing a package the data files were wiped out too.
- It's not possible to query the user at uninstall time as to the
disposition of data files because the uninstall (like install's) may be scripted.
My inclination is the packaging guidelines should encourage the removal of data files generated by the package when the package is removed.
Packages, in general, should not create data outside of what's managed by %files. A crutch that could be beneficial here is prudent use of %ghost and/or %config(missingok)
-- Rex
"RD" == Rex Dieter rdieter@math.unl.edu writes:
RD> Packages, in general, should not create data outside of what's RD> managed by %files.
Of course, the devil is in the specifics. I wouldn't expect that uninstalling a package would remove its logs, for example.
I would hope that packagers would think about the data generated by the running code and consider whether there's a valid reason for keeping it around after the package is removed, or conversely whether removing it is likely to delete something that the user expects to keep. Actually deleting useful data is something to be avoided at all costs.
I suspect that there's no other rules that could be applied other than common sense and the principle of least surprise.
- J<
Should just note here that dpkg is quite nuanced in how it removes packages compared to rpm:
There are two states: normal removal of a package doesn't remove any configuration files. That's so you can reinstall a package and not have to reconfigure it. So called "purge" removes the configuration files too.
I would think the same thing applies to removing generated data -- that there should be 3 states: remove just the package, remove the package and generated data, or remove the package and generated data and configuration files.
Rich.
On Wed, 18 Nov 2009, Richard W.M. Jones wrote:
Should just note here that dpkg is quite nuanced in how it removes packages compared to rpm:
There are two states: normal removal of a package doesn't remove any configuration files. That's so you can reinstall a package and not have to reconfigure it. So called "purge" removes the configuration files too.
I would think the same thing applies to removing generated data -- that there should be 3 states: remove just the package, remove the package and generated data, or remove the package and generated data and configuration files.
If y'all want to change the behavior of an rpm -e then you need to talking to the rpm-maint list at rpm.org
not here.
-sv
On 11/18/2009 07:58 PM, Richard W.M. Jones wrote:
Should just note here that dpkg is quite nuanced in how it removes packages compared to rpm:
There are two states: normal removal of a package doesn't remove any configuration files. That's so you can reinstall a package and not have to reconfigure it. So called "purge" removes the configuration files too.
I would think the same thing applies to removing generated data -- that there should be 3 states: remove just the package,
great, let's just ignore %config(noreplace) / %config
remove the package and generated data,
I would be more than unpleasantly surprised if rpm -e mysql-server would remove the databases as well (you know, I might just want to move them to another server and I've started by removing the software first) or rpm -e rrdtool would remove all the collected / processed data. And so on, you get the drill. That is, unless you teach rpm about "--purge" or something similar, which should be neither default nor discussed on this list but in rpm's upstream.
or remove the package and generated data and configuration files.
packaging@lists.fedoraproject.org