Smart should allow using a compressed-only channel file

I usually delete all files except *.repomd.xml files on Fedora to reduce disk space usage and this has not caused any problems (so far, unless smart is silently having problems with this). Updates proceed as normal as only the repomd.xml files are checked to see if the channel has updated. Is there a similar case for other supported channels? Perhaps a cleanup function can be implemented after a channel update completes successfully?

Just tested this (Fedora 8). The only time this leaves a inconsistent DB is if the non-repomd.xml are deleted and the cache file is also deleted. In this case if the files were available the cache would be re-built from the files in channels but as they are missing it ignores those channels. Perhaps this situation (no cache file + incomplete channel data) should trigger an update request to the user?

Rehan, this is not supported use of Smart. Either a feature should be implemented
to use only the compressed file, or this issue should be closed as that's the way it
works. The cache is a cache, and it may be removed during package upgrades or
at any moment desired by the system, without bad consequences for the usage.

We discussed this for other formats too, as they all have similar issues.
It's a tradeoff between disk space and processing time used, in the end.

As an example, here are the compressed/uncompressed file sizes from fedora 9, opensuse 11, mandriva 2008.1 and ubuntu hardy...

Ok I've done a bit of additional testing. If the uncompressed files are deleted and smart needs to go to the channel files it will uncompress the compressed files if the uncompressed files are not available (and the compressed files are). I tested this in the case of starting smart with the uncompressed archives and cache files deleted, leaving the compressed files (the metadata downloaded from the mirror). I think deleting the uncompressed files after they have been used to populate the cache is a good interim solution until the use of compressed files directly is available.

To summarise: always leave the compressed file in place, delete the uncompressed files after they have been used. Smart should cope with this and the users (don't forget these people!) will be much happier. As you guys are more familiar with the code could you point me in the right direction. I'd like to have a look at this to see if it is feasible. It should be only a small change.

Changing importance to "Wishlist" as the core development team decided this is not a bug, but a new feature request.

By the way Smart is designed, it's not clean to erase the uncompressed files after usage. A proper implementation would be adding support for Smart to read the compressed files directly.

More testing is needed to check how viable/interesting is that solution.