tags 663382 important retitle 663382 fallback to cupt-specific extended_states file quit
Hello Raphael, thank you for testing, On 2012-03-10 13:18, Raphael Geissert wrote: > After removing apt with cupt, cupt is useless: > > # cupt install apt > Building the package cache... > E: unable to open file '//var/lib/apt/extended_states': No such file or > directory /var/lib/apt/extended_states is the file where the information about automatically installed packages is stored. This information is not specific to libapt and should ideally be shared between high-level packages, yet this not the current state of affairs. Cupt does not need apt for the work, but it needs an extended states file (for reading and writing). In unusual setups where apt is not installed at all, you can easily override the path of the file. For example, putting dir::state::extendedstates "/var/lib/cupt/extended_states"; to /etc/cupt/cupt.conf and then 'touch /var/lib/cupt/extended_states' should make cupt happy. I thus downgraded severity a bit. I agree that some fallback should be implemented by default to not require this from the user. It will be implemented. The real solution would be to move this file to a shared location which all high-level package managers can use, not sure if APT team would be willing to do it. Regardless of the Cupt-side fixes, I would say it's an error for apt to delete these kind of files even on purge, and a serious error if its deleted by a simple removal (you didn't specify the command so I can't guess was your case 'remove' or 'purge'). You may want to file a bug on apt about this. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org