Control: tags -1 + pending
Hi Josh, 2012-05-06 22:32 Josh Triplett:
Package: aptitude Version: 0.6.7-1 Severity: wishlist aptitude currently creates a cache in ~/.aptitude/cache . Please consider moving this to the standard user cache directory, $XDG_CACHE_HOME, defaulting to ~/.cache if unset. Among other things, this will make it easier to exclude the aptitude cache from backups; many backup tools already know to skip ~/.cache , and even for those that don't, excluding one path proves easier than excluding one path per program. Thanks, Josh Triplett
2014-02-09 22:43 To 671...@bugs.debian.org:
Hi, I created the attached patch, similar to Josh's but moving the cache if exists. I am fine with integrating Josh's patch as well. The reason for this new stab with the modified patch is because I think that somehow it's important to remove the litter and not leave ~/.aptitude/cache behind. I think that this file is small enough and loosing its contents unimportant enough that perhaps this is not needed (and the paraphernalia to achieve this is a bit ugly, and probably not foolproof). But in that case perhaps we should remove instead of move? Anyway, I think that it would be nice to fix this. Thanks Josh for bringing this to our attention and providing the patch.
I was working in yet-another-respin of the patch. I wanted to move away or remove the old cache file, so that if config is empty, all of ~/.aptitude can be removed; and if config is present but not modified, ~/.aptitude can stay in read-only filesystems without spawning error dialogs. (There are other bug reports about those issues, empty config and rewriting config file again and again when nothing changes, for which I also commited fixes in the last few days). Now some comments about the previous considerations: 2014-06-02 05:31 Daniel Hartwig:
After initially merging the patch, it has been reverted due to complications with file ownership and requirements of the XDG basedir specification. Briefly, the basedir specification states that non-existent directories are to be created and with initial mode 0700. The path used can come from $HOME, $XDG_CACHE_HOME, or a default.
From my reading of the spec (perhaps Josh can clarify this), in the
first URL it mentions 0700 only for another directory. In the second, it mentions it again, but it's not clear to me if it applies to all XDG_* directories or only the ones mentioned in that page. It is very odd to mention this only in a section called "Referencing this specification", instead of a possible "Implementation details" or when explaining about the different dirs in "Environment variables". http://standards.freedesktop.org/basedir-spec/latest/ar01s03.html http://standards.freedesktop.org/basedir-spec/latest/ar01s04.html In any case, my implementation addresses this.
Not an issue for programs run under the effective id of the logged in user. But that is not how aptitude is always run. Different means of gaining root privileges do filter any of these environment variables, and it is not clear whether the user has intentionally or not set any of them, nor which user is supposed to own the cache directories once created. Example: $ export XDG_CACHE_HOME=/usercache/foo # perhaps set on login ... $ su ... $ aptitude Counter example: $ su ... $ export XDG_CACHE_HOME=/rootcache $ aptitude su _may_ have cleared XDG_CACHE_HOME or may not have, depending on system configuration. It is not obvious to aptitude whether the user is expecting this to have been passed to aptitude, nor which user should have ownership of the stated path if aptitude has to create it. Other scenarios introduce similar ambiguity.
I changed the invocation of "su" due to another bug to also call with "--login", which should make this program to further clear the environment vars from the user. In any case, when user is root it respects the user and permissions of the files that it modifies. The file is created anew upon start of aptitude if it doesn't exist or it was deleted (before being able to "become root"), so it will be created as either user or root in the respective XDG_*/HOME directory, so this shouldn't be a problem. If the user goes out of the way and specify their own become-su program without these guarantees of cleaning the environment, and also decide to specify/change their own XDG directories back and forth, etc., the worst that can happen is that they will see an error, upon which they will receive an error and can take action to resolve the issue -- or report a bug, and we will know about such use-cases. This is not very different for what currently happens with ~/.aptitude/ anyway, similar problems can happen if one plays with HOME when becoming root. So basically, this is implemented now and was commited to VCS, so marking as +pending. Hopefully it will not be pulled out again before release. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
