[Aptitude-devel] Bug#671780: Please move ~/.aptitude/cache to $XDG_CACHE_HOME (default ~/.cache)

[Manuel A. Fernandez Montecelo]

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 671780 at 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.montezelo at gmail.com>