Re: best approach for cleaning package metadata cache for old versions on upgrade?
Rex Dieter wrote: % yum includes arch/release subdirs under /var/cache/yum, the important part % is the "release" part. So, it is theoretically easy to identify which parts % are worth keeping and which ones are not (ie, does the release/ subdir match % the current release or not). ie, % $ ls -F /var/cache/yum/x86_64/ % 24/ % % PackageKit seems to follow that practice at least partially: % $ ls -F /var/cache/PackageKit/ % 24/ downloads/ metadata/ % % dnf seems to not do that, but I'd suggest adding that could help. Dnf left releasever out intentionally. See https://bugzilla.redhat.com/show_bug.cgi?id=1173107 -- Michael Mráka Software Management Engineering, Red Hat -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: best approach for cleaning package metadata cache for old versions on upgrade?
Matthew Miller wrote: > There is a thread on the users' list * dealing with the issue that > after an upgrade, there's no non-obscure way to clean cached metadata > (or packages, even) from previous releases. The thread discussses DNF > and Yum, but it may apply to PackageKit/Software as well; I'm not sure > offhand. > > It seems like we should handle this in some way on upgrade. My first > thought was to make it an RFE dnf-plugin-system-upgrade. But, is that > the right place? Maybe some time-base system should prune metadata > associated with repositories for any earlier $releasever? (Or, > actually, maybe for any repository which does not match a current > configuration?) Or maybe a "dumb" process to sweep the cache based on > age alone would do? yum includes arch/release subdirs under /var/cache/yum, the important part is the "release" part. So, it is theoretically easy to identify which parts are worth keeping and which ones are not (ie, does the release/ subdir match the current release or not). ie, $ ls -F /var/cache/yum/x86_64/ 24/ PackageKit seems to follow that practice at least partially: $ ls -F /var/cache/PackageKit/ 24/ downloads/ metadata/ dnf seems to not do that, but I'd suggest adding that could help. -- Rex -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: best approach for cleaning package metadata cache for old versions on upgrade?
On Fri, Apr 15, 2016 at 11:26:02AM -0400, Matthias Clasen wrote: > > Do you think you can remove cache of any package without the crash? > > I remember cleaning cache for docker (even after properly deleting > > the saved > > images) and I was not able to get it work again. > Thats part of the semantics of /var/cache/, isn't it ? > > If you place something there, you are basically saying: Removing this > won't affect the functionality of this package. Yes, this is definitely true by the FHS, which says * Files located under /var/cache may be expired in an application specific manner, by the system administrator, or both. The application must always be able to recover from manual deletion of these files (generally because of a disk space shortage). No other requirements are made on the data format of the cache directories. Unfortunately, that doesn't guarantee that all applications are well-behaved. * http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s05.html -- Matthew Miller Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: best approach for cleaning package metadata cache for old versions on upgrade?
On Fri, 2016-04-15 at 09:08 -0400, Honza Šilhan wrote: > Do you think you can remove cache of any package without the crash? > I remember cleaning cache for docker (even after properly deleting > the saved > images) and I was not able to get it work again. Thats part of the semantics of /var/cache/, isn't it ? If you place something there, you are basically saying: Removing this won't affect the functionality of this package. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: best approach for cleaning package metadata cache for old versions on upgrade?
> From: "Matthew Miller" > On Thu, Apr 14, 2016 at 01:16:07PM -0400, Matthias Clasen wrote: > > If you put it in the dnf plugin, you leave out the new graphical > > upgrade that is coming in F24. > > Yeah — and obviously not something I want to leave out. :) dnf system-upgrade and PK could remove cache for all releases lower than the current one after sys-upgrade (with some switch enabled). This would not solve the problem for all package cache though. > > It is also not really dnf-specific at all. Other apps or services may > > leave stuff behind in /var/cache too. One radical, but simple approach > > would be to simply rm -rf /var/cache after the upgrade. That would give > > you a system that is a bit closer to 'freshly installed' state. Do you think you can remove cache of any package without the crash? I remember cleaning cache for docker (even after properly deleting the saved images) and I was not able to get it work again. Honza -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: best approach for cleaning package metadata cache for old versions on upgrade?
On Thu, Apr 14, 2016 at 01:16:07PM -0400, Matthias Clasen wrote: > If you put it in the dnf plugin, you leave out the new graphical > upgrade that is coming in F24. Yeah — and obviously not something I want to leave out. :) > It is also not really dnf-specific at all. Other apps or services may > leave stuff behind in /var/cache too. One radical, but simple approach > would be to simply rm -rf /var/cache after the upgrade. That would give > you a system that is a bit closer to 'freshly installed' state. That's an interesting idea. Where would this happen? -- Matthew Miller Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: best approach for cleaning package metadata cache for old versions on upgrade?
On Thu, Apr 14, 2016 at 11:16 AM, Matthias Clasen wrote: > It is also not really dnf-specific at all. Other apps or services may > leave stuff behind in /var/cache too. One radical, but simple approach > would be to simply rm -rf /var/cache after the upgrade. That would give > you a system that is a bit closer to 'freshly installed' state. I think that's a great idea, really. There's fontconfig/ and man/ that accumulate files, and I have no idea if that can become stale in a way newer versions don't account for, and we really shouldn't have to find out the hard way. Just blow it all away and let it rebuild. This is consistent with the PRD "Robust Upgrades" plan. -- Chris Murphy -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: best approach for cleaning package metadata cache for old versions on upgrade?
On Qui, 2016-04-14 at 12:51 -0400, Matthew Miller wrote: > There is a thread on the users' list * dealing with the issue that > after an upgrade, there's no non-obscure way to clean cached metadata > (or packages, even) from previous releases. The thread discussses DNF > and Yum, but it may apply to PackageKit/Software as well; I'm not > sure > offhand. > > It seems like we should handle this in some way on upgrade. My first > thought was to make it an RFE dnf-plugin-system-upgrade. But, is that > the right place? Maybe some time-base system should prune metadata > associated with repositories for any earlier $releasever? (Or, > actually, maybe for any repository which does not match a current > configuration?) Or maybe a "dumb" process to sweep the cache based on > age alone would do? > > > * http://lists.fedoraproject.org/archives/list/users@lists.fedoraproj > ect.org/message/43OZYUTGFVZG6DTFKTJRHLUC7MET7LCB/ > rm -rf /var/cache/dnf /var/cache/yum /var/cache can be remove safely -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: best approach for cleaning package metadata cache for old versions on upgrade?
On Thu, 2016-04-14 at 12:51 -0400, Matthew Miller wrote: > There is a thread on the users' list * dealing with the issue that > after an upgrade, there's no non-obscure way to clean cached metadata > (or packages, even) from previous releases. The thread discussses DNF > and Yum, but it may apply to PackageKit/Software as well; I'm not > sure > offhand. > > It seems like we should handle this in some way on upgrade. My first > thought was to make it an RFE dnf-plugin-system-upgrade. But, is that > the right place? Maybe some time-base system should prune metadata > associated with repositories for any earlier $releasever? (Or, > actually, maybe for any repository which does not match a current > configuration?) Or maybe a "dumb" process to sweep the cache based on > age alone would do? > If you put it in the dnf plugin, you leave out the new graphical upgrade that is coming in F24. It is also not really dnf-specific at all. Other apps or services may leave stuff behind in /var/cache too. One radical, but simple approach would be to simply rm -rf /var/cache after the upgrade. That would give you a system that is a bit closer to 'freshly installed' state. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
best approach for cleaning package metadata cache for old versions on upgrade?
There is a thread on the users' list * dealing with the issue that after an upgrade, there's no non-obscure way to clean cached metadata (or packages, even) from previous releases. The thread discussses DNF and Yum, but it may apply to PackageKit/Software as well; I'm not sure offhand. It seems like we should handle this in some way on upgrade. My first thought was to make it an RFE dnf-plugin-system-upgrade. But, is that the right place? Maybe some time-base system should prune metadata associated with repositories for any earlier $releasever? (Or, actually, maybe for any repository which does not match a current configuration?) Or maybe a "dumb" process to sweep the cache based on age alone would do? * http://lists.fedoraproject.org/archives/list/us...@lists.fedoraproject.org/message/43OZYUTGFVZG6DTFKTJRHLUC7MET7LCB/ -- Matthew Miller Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
