{"action":"created","issue":{"url":"https://api.github.com/repos/Zirak/pkgfs/issues/6","labels_url":"https://api.github.com/repos/Zirak/pkgfs/issues/6/labels{/name}","comments_url":"https://api.github.com/repos/Zirak/pkgfs/issues/6/comments","events_url":"https://api.github.com/repos/Zirak/pkgfs/issues/6/events","html_url":"https://github.com/Zirak/pkgfs/issues/6","id":98792288,"number":6,"title":"Caching behaviors","user":{"login":"ralt","id":1016379,"avatar_url":"https://avatars.githubusercontent.com/u/1016379?v=3","gravatar_id":"","url":"https://api.github.com/users/ralt","html_url":"https://github.com/ralt","followers_url":"https://api.github.com/users/ralt/followers","following_url":"https://api.github.com/users/ralt/following{/other_user}","gists_url":"https://api.github.com/users/ralt/gists{/gist_id}","starred_url":"https://api.github.com/users/ralt/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ralt/subscriptions","organizations_url":"https://api.github.com/users/ralt/orgs","repos_url":"https://api.github.com/users/ralt/repos","events_url":"https://api.github.com/users/ralt/events{/privacy}","received_events_url":"https://api.github.com/users/ralt/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2015-08-03T16:50:13Z","updated_at":"2015-08-03T17:59:47Z","closed_at":null,"body":"So, the fact that pkgfs implementations are a representation of the package manager at time T means several things:\r\n\r\n- Either we build the whole tree at startup time and it gets outdated as soon as something changes. (what you do in pacman-fs)\r\n- Or we return the relevant tree at call time, so it's always up-to-date, but is also very slow. (what I do at dpkg-fs)\r\n\r\nHaving a short-lived cache for some specific things (like some API calls) can be useful (e.g. I `ls /pkg/installed/foo/files/`, not having to call `dpkg -L foo` for every file is useful.), but it doesn't cover other, more important cases like `ls /pkg/installed`.\r\n\r\nI think I can get a cache based on the mtime of `/var/lib/dpkg/lock`, can you also get something similar with libalpm?"},"comment":{"url":"https://api.github.com/repos/Zirak/pkgfs/issues/comments/127351745","html_url":"https://github.com/Zirak/pkgfs/issues/6#issuecomment-127351745","issue_url":"https://api.github.com/repos/Zirak/pkgfs/issues/6","id":127351745,"user":{"login":"ralt","id":1016379,"avatar_url":"https://avatars.githubusercontent.com/u/1016379?v=3","gravatar_id":"","url":"https://api.github.com/users/ralt","html_url":"https://github.com/ralt","followers_url":"https://api.github.com/users/ralt/followers","following_url":"https://api.github.com/users/ralt/following{/other_user}","gists_url":"https://api.github.com/users/ralt/gists{/gist_id}","starred_url":"https://api.github.com/users/ralt/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ralt/subscriptions","organizations_url":"https://api.github.com/users/ralt/orgs","repos_url":"https://api.github.com/users/ralt/repos","events_url":"https://api.github.com/users/ralt/events{/privacy}","received_events_url":"https://api.github.com/users/ralt/received_events","type":"User","site_admin":false},"created_at":"2015-08-03T17:59:47Z","updated_at":"2015-08-03T17:59:47Z","body":"On debian, there's actually 2 locks: one for apt (the index), another for dpkg. Which means I can have 2 caches: one for /pkg/index, and another for /pkg/installed, based on the mtimes of both /var/lib/apt/lists/lock and /var/lib/dpkg/lock.\r\n\r\nI need to investigate more though, as this is the theory. The /var/lib/apt/lists/lock file mtime is from July, as I'm speaking on my machine. So I need to confirm this.\r\n\r\nBut anyway, this sounds like a good option for me altogether.\r\n\r\nThe question is: can you get something similar?"}}