Re: Bug#285768: dselect survey
Hi, - If I see a new package installed by someone else, * if nothing depends on it, mark it Unknown; probably manually installed * otherwise, mark it Unknown; probably automatically installed Consider apt-get install foo apt-get remove foo This leaves libfoo1, which was pulled in by foo and is not depended on by anything, hence aptitude will consider it probably manually installed. Most cases where this feature is needed (i.e. unless migrating from another PM) are like this one, where you really want the package removed. Packages in Unknown state that are depended on by other packages could be shown in the preview in a separate section, so you can go on the section line, tap M and then manually go through the list and mark everything that is actually needed. Unknown; probably manually installed: I don't see doing anything especially fancy here, but there should be a way to show all of them on demand. Show all of them in the preview. Unknown; probably automatically installed: If one of these packages is only [transitively] depended upon by some other packages in the same class, tell the user that they all are possibly unused. (for instance, in the preview screen) Such a state would be used only seldom, it applies only to packages installed automatically with another PM where the depending package is removed with aptitude. One problem is that the set of packages that are possibly unused isn't disjoint to the other sets of packages that aptitude displays, which could perhaps lead to some awkward situations. (what if a package is both upgradable and possibly unused? Which category is it listed in, or is it listed in both?) Two categories, like the distinction between automatically installed new packages and new packages. In total, we get four new categories. Simon signature.asc Description: OpenPGP digital signature
Re: Bug#285768: dselect survey
On Wednesday 15 December 2004 09:01 am, Simon Richter wrote: aptitude could be taught to have auto-installed being Yes,No or Unknown. Whenever a package that is in Unknown state could be removed if it were only installed as a dependency, aptitude should list them in the actions to be performed view as being still installed and unknown whether they can be removed. Until I make a decision (which I am not forced to do at this moment) the package would reappear in this list everytime it could be deinstalled (i.e. until another package depending on it is installed or a decision is made). It seems like Unknown would just be a synonym for No, right? Presumably with a way to search for unknown packages (I think ~U isn't taken yet). Daniel -- /--- Daniel Burrows [EMAIL PROTECTED] --\ | Inconceivable! | | -- The Princess Bride | \ Evil Overlord, Inc: http://www.eviloverlord.com --/ pgpiEiMbkGLus.pgp Description: PGP signature
Re: Bug#285768: dselect survey
On Wed, Dec 15, 2004 at 01:53:20PM -0500, Daniel Burrows wrote: On Wednesday 15 December 2004 09:01 am, Simon Richter wrote: aptitude could be taught to have auto-installed being Yes,No or Unknown. Whenever a package that is in Unknown state could be removed if it were only installed as a dependency, aptitude should list them in the actions to be performed view as being still installed and unknown whether they can be removed. Until I make a decision (which I am not forced to do at this moment) the package would reappear in this list everytime it could be deinstalled (i.e. until another package depending on it is installed or a decision is made). It seems like Unknown would just be a synonym for No, right? Uh, yes. I think. You may want to explain that a bit more. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune
Re: Bug#285768: dselect survey
On Wednesday 15 December 2004 03:37 pm, Wouter Verhelst wrote: It seems like Unknown would just be a synonym for No, right? Uh, yes. I think. You may want to explain that a bit more. Well, from the bug report, it looks like the proposal is to maintain the current behavior, but to set a different flag on packages that were conservatively assumed to be manually installed, so they can be switched later to automatic handling if desired. Sounds useful. Daniel -- /--- Daniel Burrows [EMAIL PROTECTED] --\ | Thank you for reading me, but the real .signature is in another email. | \- Does your computer have Super Cow Powers? --- http://www.debian.org -/ pgpzIku2aqCBx.pgp Description: PGP signature
Re: Bug#285768: dselect survey
On Wed, Dec 15, 2004 at 04:02:03PM -0500, Daniel Burrows wrote: On Wednesday 15 December 2004 03:37 pm, Wouter Verhelst wrote: ? It seems like Unknown would just be a synonym for No, right? Uh, yes. I think. You may want to explain that a bit more. Well, from the bug report, it looks like the proposal is to maintain the current behavior, but to set a different flag on packages that were conservatively assumed to be manually installed, so they can be switched later to automatic handling if desired. Sounds useful. Well, in that case, not entirely. You may also want to set a flag on packages that are assumed to be automatically installed, but of which you have no information. Consider libgnome2-perl: people may want to install that, even if there is no dependency, to allow for debconf to provide a gnome frontend; however, I can imagine there are also packages that have a dependency on libgnome2-perl. Now consider a user who recently switched to aptitude after having used a different frontend for a long while; this user had installed libgnome2-perl manually (for the debconf frontend), but later on installed just one package depending on libgnome2-perl to see what it does. At that time, the switch to aptitude was made; but then the user decided that the package using libgnome2-perl isn't useful enough, and removes it again. What debfoster will do in that case, is present the user with libgnome2-perl (and all packages whom only libgnome2-perl depends on and for which no preference is yet known), and ask whether they should be removed. I really think this is the right thing to do in such a situation. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune
Re: Bug#285768: dselect survey
On Wednesday 15 December 2004 07:51 pm, Wouter Verhelst wrote: You may also want to set a flag on packages that are assumed to be automatically installed, but of which you have no information. aptitude never should assume that a package is automatically installed, unless it performs the automatic installation itself. I don't think any other option is really safe. (I *think* you're not talking about current behavior, but I thought I saw someone bring this up in the -devel thread that spawned this bug, and you just reminded me of it) Consider libgnome2-perl: people may want to install that, even if there is no dependency, to allow for debconf to provide a gnome frontend; however, I can imagine there are also packages that have a dependency on libgnome2-perl. Now consider a user who recently switched to aptitude after having used a different frontend for a long while; this user had installed libgnome2-perl manually (for the debconf frontend), but later on installed just one package depending on libgnome2-perl to see what it does. At that time, the switch to aptitude was made; but then the user decided that the package using libgnome2-perl isn't useful enough, and removes it again. What debfoster will do in that case, is present the user with libgnome2-perl (and all packages whom only libgnome2-perl depends on and for which no preference is yet known), and ask whether they should be removed. It sounds to me like what you're proposing is something like: - If I see a new package installed by someone else, * if nothing depends on it, mark it Unknown; probably manually installed * otherwise, mark it Unknown; probably automatically installed Then you'd have two more classes of packages, in addition to manual and automatic: Unknown; probably manually installed: I don't see doing anything especially fancy here, but there should be a way to show all of them on demand. Unknown; probably automatically installed: If one of these packages is only [transitively] depended upon by some other packages in the same class, tell the user that they all are possibly unused. (for instance, in the preview screen) One problem is that the set of packages that are possibly unused isn't disjoint to the other sets of packages that aptitude displays, which could perhaps lead to some awkward situations. (what if a package is both upgradable and possibly unused? Which category is it listed in, or is it listed in both?) Daniel -- /--- Daniel Burrows [EMAIL PROTECTED] --\ | Hah, I can just see a real playsmith puttin' a..a DONKEY in a play! | | -- Terry Pratchett, _Lords and Ladies_| \-- (if (not (understand-this)) (go-to http://www.schemers.org)) ---/ pgpzJ1fg1NoVu.pgp Description: PGP signature
