On Sat, 27 Mar 2010, Robert Luberda wrote: > I discovered that the previous version of my patch re-added the "purge > ok not-installed" packages into status file. Fortunately the issue > turned out to be quite simple to fix. I'm attaching a new patch split > into two files. > > The first one, 1_dselect_559519+556889.patch.gz, causes dselect to treat > all unknown packages all as already seen. This fixes #556889, since > dselect never automatically selects already seen packages for installation. > The change is especially visible at the packages' selection screen: the > non-patched version shows status `n_' (meaning `new purge') for most > packages, for example: > n_ Xtr x11 choosewm <none> 0.1.6-1 fake ... > n_ Xtr x11 compiz-fusio <none> 0.8.4-1 Compiz Fusion ... > n_ Xtr x11 compiz-fusio <none> 0.8.4-2 Compiz Fusion ... > My version displays the status as '__' (`purge purge'). > I hope the patch would be quite safe for applying in dselect. > > > With the second patch, 2_dselect_551638.patch.gz, dselect stores already > seen packages in packages-seen file - one package name in each line. It > would be nice if you could apply this patch too, even though you might > dislike it e.g. because db is certainly not `fronted united', coding > introduces usage of STL maps, strings and iostreams and doesn't look > like the awful `C with classes' used elsewhere in dselect codes.
How can the two patches work together? I mean either the package has been already seen or it's not. 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? 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. 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. In the mean time, I think committing your first patch would alleviate the most annoying side-effects of the current situation. I would be in favor of that, Guillem what do you think? Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
