Raphael Hertzog writes: > > How can the two patches work together? I mean either the package has been > already seen or it's not.
The second patch complements to the first one, i.e. the latter depends on and extends the former one. Currently dselect treats all unknown packages as unseen, which is clearly visible by users and causes the behaviour reported in #556889. > > A new package by definition has no entry in the status file so it's > unknown (and thus seen) according to the first patch. What good does the > second patch do then? In short the first patch makes dselect to treat all unknown packages as already seen, whereas the second one adds to it ability to distinguish between seen and unseen packages (so with the second patch unknown packages are no longer all seen by default). As you can see, the second patch contains amongst others the following change: - state->direct= state->original= (pkg->want == pkginfo::want_unknown ? pkginfo::want_purge : pkg->want); + state->direct= state->original= (pkg->want == pkginfo::want_unknown && seen ? pkginfo::want_purge : pkg->want); ^^^^^^^ > > Otherwise I discussed your patch with Guillem quickly the other day and he > would like to store the seen/not-seen information in a common place (i.e. > shared by all frontends). I'm not sure there's enough time to implement > this in the squeeze timeframe. Guillem mentionnend reverting part of the > problematic changes if he can't manage this in time, I'm not sure I like > this, I would rather commit something based on your patch. I was aware of Guillem's intentions, after all he put the magic `frontend-unified state file' phrase in the bug's #551638 description :) I think it's a nice idea, but probably not for squeeze. Even if you manage to add such a file into dpkg on time for squeeze, most probably aptitude, synaptic and any other frontend (besides dselect) won't switch to using it so fast. So how about implementing temporary dselect-only solution for now and implementing the proper solution for squeeze + 1? > > In that case, if we store the data in a frontend-specific manner, the file > shall be stored in /var/lib/dselect and not /var/lib/dpkg. Our goal is to > prepare a split so new files should go there IMO. That's OK. I've put it in $admindir for simplicity and not to care about locking the file as the any reads/writes are done where dpkg's status database in locked. If you put the file somewhere else probably: - either you would need to add some locking - or the file location would need to depend on $admindir (like $admindir/../dselect/, but it's quite strange) - eventually you would need to drop the --admindir option from dselect (honestly I've never used it). > > In the mean time, I think committing your first patch would alleviate the > most annoying side-effects of the current situation. I second this. > I would be in favor > of that, Guillem what do you think? Regards, robert > > Cheers, -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
