Re: Annoyances of aptitude (Was: Where are we now?) (Was: Bits from the RM)
On Thu, Oct 02, 2003 at 07:43:37PM -0400, Nathanael Nerode wrote: Eventually I found aptitude's Dselect theme, which helped some. I guess aptitude could be made the recommended default package manager, but I would hope that: 1. Something more closely approximating the Dselect theme is used by default, so that dselect users don't get utterly lost. I don't see any particular reason why aptitude should need to cater to dselect users, considering that we still ship dselect (as essential, no less), and dselect users are more than welcome to continue using it for as long as it is maintained. It is more important to provide something that does not cause _everyone else_ to get utterly lost, and let dselect users use dselect. 2. Remove unused packages automatically is (a) better described and (b) off by default. I've never had a problem, either with understanding or using this feature. -- - mdz
Re: Re: Annoyances of aptitude (Was: Where are we now?) (Was: Bits from the RM)
Daniel Burrows wrote: (e) I've heard about a debtags database system that's trying to find a general solution to the problem of categorizing packages. I took a look at their library at one point and wasn't able to figure out how to use it, but if this project is still going somewhere, supporting it in aptitude would be nice. You can try out debtags either via the web interface at http://debian.vitavonni.de/packagebrowser/ or by installing the synaptic-debtags package, which has a debtags view. (In views, select tag view) Thanks to mvo and enrico for doing this synaptic integration at debconf. Of course there is still room for improvement, but this is the slickest interface i know. ;-) This to improve in synaptic-debtags: - make the tree less deep, don't make subfolders if only 10 packages are left etc. - show tag descriptions. - handle virtual tags in the tree, such as ui, which basically is a union of ui::gtk, ui::qt, ui::ncurses etc. (virtual tags: tags where all packages are in a subgroup) Things to improve with debtags in general: - more tagging. Too many packages are still untagged - inconsistent tagging. New tags were added, so many tagged packages are incompletely tagged. For example many applications don't have a user interface specified. - inconsistent tags. some features have tags, others don't. - structure is becoming to deep IMHO. but if you want to keep the number-of-results low you need such a deep structure. Gruss, Erich Schubert -- erich@(vitavonni.de|debian.org)--GPG Key ID: 4B3A135C(o_ The best things in life are free: Friendship and Love. //\ Die eigentliche Aufgabe eines Freundes ist, dir beizustehen,V_/_ wenn du im Unrecht bist. Jedermann ist auf deiner Seite, wenn du im Recht bist. --- Mark Twain
Re: Annoyances of aptitude (Was: Where are we now?) (Was: Bits from the RM)
On Thu, Oct 02, 2003 at 10:59:15PM -0400, Daniel Burrows wrote: (e) I've heard about a debtags database system that's trying to find a general solution to the problem of categorizing packages. I took a look at their library at one point and wasn't able to figure out how to use it, but if this project is still going somewhere, supporting it in aptitude would be nice. Still going somewhere, I hope :) It's been paused for a while because I've been away for quite some time, but I'm still committed to work on it (although, unfortunately, I can only do it in the free time). I know there is no documentation on the library API, and this is documented ( :-) ) in /usr/share/doc/libtagcoll-dev/README: There's a reason: before producing documentation, I'd like to discuss with other potential users about what could be the shape of a stable API for this library. and Please get in touch with me also if you start using libtagcoll in some projects: since the API is going to change, at least I'd have a chance to take you into account. So, if you start using libtagcoll in some projects, please get in touch with me and I'll be more than happy to help you :-) Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Annoyances of aptitude
Daniel Burrows wrote: (h) ummm, I can't think of anything else right now. Listing the release (stable/testing/unstable or woody/sarge/sid) it comes from next to the versions of a package would be nice. Just my .02 EUR. -- Kurt Bernhard Pruenner Telefon: 0732/2468-7135 Techniker Gr. SystemsoftwareFax: 0732/2468-7138 np: Plaid - Zala (Double Figure)
Re: Annoyances of aptitude
On Fri, 03 Oct 2003 21:40:06 +0200, Micha Politowski wrote: [locating broken packages] Usually I just press l~bEnter Cool, thanks. I didn't know that trick. (The German translation of the l feature is misleading, no it's actually totally wrong... It never occurred to me that this keybinding could be useful. Bug report filed.) Limited views are (together with GC, and command-line search) probably the three features of aptitude I couldn't live without. Does my feature request still make some sense? -- Best Regards, | Wer Windows-Rechner ins Internet lsst, Sebastian | braucht nicht ber SWEN stnkern! | | mailbox in From silently drops any mail 20k
Re: Annoyances of aptitude (Was: Where are we now?) (Was: Bits from the RM)
On Fri, Oct 03, 2003 at 02:07:00PM -0400, Daniel Burrows wrote: The way this garbage collection is implemented is one of the main dislikes I have about aptitude. Aptitude contains a database with packages that have been installed through aptitude; as such, it contains no information on packages that were installed through a different dpkg-frontend. Which is no problem in itself, except that aptitude assumes a package which has not been installed through aptitude is not wanted; this makes a transition from a different dpkg-frontend to aptitude cumbersome, to say the least. This behavior is obviously terrible, which is why aptitude doesn't try to implement it. Ah. Oh. Of course, as ccheney pointed out recently, there are always bugs. Can you show me a case where, starting with no aptitude state information, you run aptitude and get any package on the system marked as automatically installed? (one exception is stuff that really is automatically installed in order to perform the upgrade-on-start) I can't. As said, I tried it only once, and it was a while ago. I just tested this on my computer and it behaves as I expect. I wonder if you somehow accidentally marked everything as automatic the first time you used aptitude (or used a buggy version, although I don't remember any released version with this particular bug), then saved those states and forgot about it? That is possible. If what happened to me is not the intended behaviour, then please ignore my last mail :-) -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Digital signature
Re: Annoyances of aptitude (Was: Where are we now?) (Was: Bits from the RM)
On 2003-10-03, Daniel Burrows [EMAIL PROTECTED] wrote: I see. It's a lot simpler, from the point of view of maintainability, to have a single user's manual for both offline and online perusal. One nice way to make this less of an issue would be to rewrite the documentation in a structured format (eg, texinfo or docbook) and add a reader for that format to aptitude. Unfortunately, writing the reader could be a lot of work. Why not use the 'info' reader? It's not optimal, but almost anything is better than paging through a long text file. Peace, Dylan
Re: Annoyances of aptitude (Was: Where are we now?) (Was: Bits from the RM)
On 02-Oct-03, 21:59 (CDT), Daniel Burrows [EMAIL PROTECTED] wrote: The Users Manual starts with a section on the non-interactive interface. Huh? I suppose the command-line interface could be documented later, but it's usually documented earlier. Or are you objecting to the odd phrase non-interactive interface? I think his point is that if one is in the interactive interface, and uses the the menu to view the User's Manual, one is probably not too interested in the command line options. :-) The command line options should probably be left out of the text displayed in the interactive environment, or moved to the end. There's task information in the database, but no mapping to human-readable names. Would you prefer that tasks be hidden entirely? Yeah, if you can't properly support tasks, there's no point in displaying that section. [ Get menu with ESC or Ctrl-space ] ESC doesn't work for me, either on the console or in rxvt. It will never be off by default while I am a maintainer of the package, unless someone gets me to change my mind (which I don't think is likely; I already thought for a while about this before changing the default to be on) You might consider including a default filter so that the only candidates for automatic removal begin with 'lib' and don't end with '-dev'. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: Annoyances of aptitude (Was: Where are we now?) (Was: Bits from the RM)
Steve Greenland wrote: You might consider including a default filter so that the only candidates for automatic removal begin with 'lib' and don't end with '-dev'. This seems rather silly. The whole point of this feature is to distinguish those packages that you manually requested from those that were installed solely because of Depends, Recommends, or Suggests in another package. The idea here, rather obviously, is that if I install package A, then remove it, I should have my system pretty much back to the state it was in before I installed A (modulo any conffiles that may be left behind, since aptitude doesn't purge auto-removed packages, just removes them). This isn't true with dselect because everything that A depends on that I didn't already have is left behind. Aptitude fixes this problem in a general way that applies to all types of packages. Limiting it to lib packages, and/or excluding -dev packages, makes the fix less generally effective. Specific examples that would be broken by your suggestion: - debian-goodes, wmget, and a handful of other packages depend on curl. If they are all removed, and the auto-remove flag is set on curl (indicating that you don't want curl for itself, but only because the other packages use it), then curl should also be removed. - kde-devel depends on several other packages, some of which don't begin with lib, others of which are lib-*dev. Again, if these packages were only installed because of kde-devel, they should be removed when kde-devel is removed. Clear the auto-remove flag if you want to keep them. Note also that aptitude will always show you what it's going to do before it does it, so it's trivial to hit '+' on packages that are about to be auto-removed if you want to keep them. Craig signature.asc Description: Digital signature
Re: Annoyances of aptitude (Was: Where are we now?) (Was: Bits from the RM)
Op vr 03-10-2003, om 04:59 schreef Daniel Burrows: Figuring out how to tell aptitude not to automatically delete unused packages required reading the User Manual while knowing that this was an issue. This is on by default, and the information about marking a package manually selected or not does not immediately spring to mind as having anything to do with whether a package is unused or not. Perhaps if it said Remove unused automatically-installed packages automatically ? ;-) In most cases, the garbage collection should operate without you needing to know about it. (the increasing prevalence of meta-packages is making this a bit tricky -- some explicit marking of these beasts in the package tags might be nice) The way this garbage collection is implemented is one of the main dislikes I have about aptitude. Aptitude contains a database with packages that have been installed through aptitude; as such, it contains no information on packages that were installed through a different dpkg-frontend. Which is no problem in itself, except that aptitude assumes a package which has not been installed through aptitude is not wanted; this makes a transition from a different dpkg-frontend to aptitude cumbersome, to say the least. I much prefer the way debfoster handles this problem; instead of trying to find out automatically, based on actions that happened in the past, whether a package is wanted, debfoster plainly asks the user whether a package on which no other package depends, and that is not yet in its database, is wanted or not. This requires a lot of input for someone running debfoster for the first time on a system with already a lot of packages installed, but since it does not try to be 'smart', it does give me the feeling of having control, which wasn't the case when I last tried aptitude after having installed some hundreds of packages already. Of course, I must add that I only tried aptitude a few times; when I saw it suddenly uninstalling packages I use a lot, I kicked it off of my hard disk :-) -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: Annoyances of aptitude (Was: Where are we now?) (Was: Bits from the RM)
Wouter Verhelst wrote: The way this garbage collection is implemented is one of the main dislikes I have about aptitude. Aptitude contains a database with packages that have been installed through aptitude; as such, it contains no information on packages that were installed through a different dpkg-frontend. Which is no problem in itself, except that aptitude assumes a package which has not been installed through aptitude is not wanted; this makes a transition from a different dpkg-frontend to aptitude cumbersome, to say the least. I don't know if this might be a bug that has crept in at some point, but when I first used aptitude, it assumed that everyone on my machine was _not_ to be automatically removed. Which seems like the right default. Craig signature.asc Description: Digital signature
Re: Annoyances of aptitude (Was: Where are we now?) (Was: Bits from the RM)
On Fri, Oct 03, 2003 at 06:34:29PM +0200, Wouter Verhelst [EMAIL PROTECTED] was heard to say: Op vr 03-10-2003, om 04:59 schreef Daniel Burrows: In most cases, the garbage collection should operate without you needing to know about it. (the increasing prevalence of meta-packages is making this a bit tricky -- some explicit marking of these beasts in the package tags might be nice) Incidentally, the problem I was referring to here is: (a) user installs kde (b) kdemultimedia (chosen for, ummm, no particular reason :P ) has a bug which makes kde uninstallable (c) aptitude sees a dependency problem and wants to remove kde (d) all of KDE is removed. It might be that the real solution here is don't be so aggressive about removing packages to solve dependency conflicts. The way this garbage collection is implemented is one of the main dislikes I have about aptitude. Aptitude contains a database with packages that have been installed through aptitude; as such, it contains no information on packages that were installed through a different dpkg-frontend. Which is no problem in itself, except that aptitude assumes a package which has not been installed through aptitude is not wanted; this makes a transition from a different dpkg-frontend to aptitude cumbersome, to say the least. This behavior is obviously terrible, which is why aptitude doesn't try to implement it. Of course, as ccheney pointed out recently, there are always bugs. Can you show me a case where, starting with no aptitude state information, you run aptitude and get any package on the system marked as automatically installed? (one exception is stuff that really is automatically installed in order to perform the upgrade-on-start) I just tested this on my computer and it behaves as I expect. I wonder if you somehow accidentally marked everything as automatic the first time you used aptitude (or used a buggy version, although I don't remember any released version with this particular bug), then saved those states and forgot about it? Daniel -- / Daniel Burrows [EMAIL PROTECTED] ---\ |If we do not change our direction| |we are likely to end up where we are headed. | \--- (if (not (understand-this)) (go-to http://www.schemers.org)) /
Re: Annoyances of aptitude (Was: Where are we now?) (Was: Bits from the RM)
On 03-Oct-03, 10:49 (CDT), Craig Dickson [EMAIL PROTECTED] wrote: Steve Greenland wrote: You might consider including a default filter so that the only candidates for automatic removal begin with 'lib' and don't end with '-dev'. This seems rather silly. The whole point of this feature is to distinguish those packages that you manually requested from those that were installed solely because of Depends, Recommends, or Suggests in another package. [*snip*] Note also that aptitude will always show you what it's going to do before it does it, so it's trivial to hit '+' on packages that are about to be auto-removed if you want to keep them. Look, *I* understand the feature, and I leave it on with no filters, and I always look at what apt is going to do before I tell it to do it. But people in the thread have been complaining about being surprised by it, and losing vital (in their environment) packages. My initial response is well, it's your own damn fault, didn't you look at the preview screen?, but then I thought maybe a little more restrained use of the feature might make them happier. But you're right, you can't prevent careless people from being careless. Either enable by default or disable by default, but no half measures. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: Annoyances of aptitude (Was: Where are we now?) (Was: Bits from the RM)
On Fri, Oct 03, 2003 at 09:53:33AM -0500, Steve Greenland [EMAIL PROTECTED] was heard to say: On 02-Oct-03, 21:59 (CDT), Daniel Burrows [EMAIL PROTECTED] wrote: The Users Manual starts with a section on the non-interactive interface. Huh? I suppose the command-line interface could be documented later, but it's usually documented earlier. Or are you objecting to the odd phrase non-interactive interface? I think his point is that if one is in the interactive interface, and uses the the menu to view the User's Manual, one is probably not too interested in the command line options. :-) The command line options should probably be left out of the text displayed in the interactive environment, or moved to the end. I see. It's a lot simpler, from the point of view of maintainability, to have a single user's manual for both offline and online perusal. One nice way to make this less of an issue would be to rewrite the documentation in a structured format (eg, texinfo or docbook) and add a reader for that format to aptitude. Unfortunately, writing the reader could be a lot of work. There's task information in the database, but no mapping to human-readable names. Would you prefer that tasks be hidden entirely? Yeah, if you can't properly support tasks, there's no point in displaying that section. I guess it depends what you mean by properly support -- the packages are all there, sorted into categories; all that's missing is the ability to, eg, display Development/C++ instead of devel-c++ (or whatever), and the long descriptions of the tasks. [ Get menu with ESC or Ctrl-space ] ESC doesn't work for me, either on the console or in rxvt. Oops, I guess it doesn't. Apparently I was misthinking. Daniel -- / Daniel Burrows [EMAIL PROTECTED] ---\ | All generalizations are dangerous. | \--- (if (not (understand-this)) (go-to http://www.schemers.org)) /
Re: Annoyances of aptitude
Wouter Verhelst [EMAIL PROTECTED] wrote: Op vr 03-10-2003, om 04:59 schreef Daniel Burrows: [...] In most cases, the garbage collection should operate without you needing to know about it. (the increasing prevalence of meta-packages is making this a bit tricky -- some explicit marking of these beasts in the package tags might be nice) The way this garbage collection is implemented is one of the main dislikes I have about aptitude. Aptitude contains a database with packages that have been installed through aptitude; as such, it contains no information on packages that were installed through a different dpkg-frontend. Which is no problem in itself, except that aptitude assumes a package which has not been installed through aptitude is not wanted; this makes a transition from a different dpkg-frontend to aptitude cumbersome, to say the least. [...] An alternative but safer way would be to record which packages were installed with aptitude only to fulfill a dependency and mark them as unwanted. cu andreas
Re: Annoyances of aptitude
On Fri, 03 Oct 2003 05:20:10 +0200, Daniel Burrows wrote: As I indicated in a recent message, I don't currently have time to get aptitude working the way I'd like. Please consider this a public call for a codeveloper -- you can interview by submitting working patches for one of the issues below, particularly the ones I've outlined a fix for. (aptitude is maintained as an Alioth project, so if you have an Alioth account, I can just add you to the project) aptitude is actually in a rather good state IMHO, it gets the job done very well. I've never grocked dselect, but once I had found out about aptitude, I was converted to the Debian side :-) A minor issue that plagues me as a Sid user is the broken packages display. When I install foo that breaks package bar by conflicts of dependencies of dependencies (you get the idea), aptitude tells me that there are broken packages. That's nice to know, but it would be even better if aptitude could display a _list_ of these packages in the g view (I mean the summary that appears just before committing the changes). With the current release, I have to browse through the packages and hope to stumble on the broken ones. This is probably not directly relevant for the Sarge release, but it would be very helpful. -- Best Regards, | Wer Windows-Rechner ins Internet lässt, Sebastian | braucht nicht über SWEN stänkern! | | mailbox in From silently drops any mail 20k
Re: Annoyances of aptitude (Was: Where are we now?) (Was: Bits from the RM)
On Fri, 03 Oct 2003 17:20:11 +0200, Steve Greenland wrote: On 02-Oct-03, 21:59 (CDT), Daniel Burrows [EMAIL PROTECTED] wrote: It will never be off by default while I am a maintainer of the package, unless someone gets me to change my mind (which I don't think is likely; I already thought for a while about this before changing the default to be on) You might consider including a default filter so that the only candidates for automatic removal begin with 'lib' and don't end with '-dev'. Huh? Don't fix things that aren't broken. For example, I don't care about cpio, though I have that package installed because dpkg-dev depends on it. Should I remove dpkg-dev one day, then I'd want cpio to leave, too. That's why cpio has the auto flag on my system. It's simple, straightforward. We don't need to discriminate against lib* packages. -- Best Regards, | Wer Windows-Rechner ins Internet lässt, Sebastian | braucht nicht über SWEN stänkern! | | mailbox in From silently drops any mail 20k
Re: Annoyances of aptitude
On Fri, Oct 03, 2003 at 08:26:28PM +0200, Andreas Metzler [EMAIL PROTECTED] was heard to say: An alternative but safer way would be to record which packages were installed with aptitude only to fulfill a dependency and mark them as unwanted. This is exactly what aptitude does (assuming unwanted means will be removed when nothing depends on it) Daniel -- / Daniel Burrows [EMAIL PROTECTED] ---\ | Genius may have its limitations, | | but stupidity is not thus handicapped.| \- Got APT? -- Debian GNU/Linux http://www.debian.org /
Re: Annoyances of aptitude
On Fri, 3 Oct 2003 20:20:33 +0200, Sebastian Kapfer wrote: [...] A minor issue that plagues me as a Sid user is the broken packages display. When I install foo that breaks package bar by conflicts of dependencies of dependencies (you get the idea), aptitude tells me that there are broken packages. That's nice to know, but it would be even better if aptitude could display a _list_ of these packages in the g view (I mean the summary that appears just before committing the changes). With the current release, I have to browse through the packages and hope to stumble on the broken ones. Usually I just press l~bEnter Limited views are (together with GC, and command-line search) probably the three features of aptitude I couldn't live without. -- Micha Politowski -- [EMAIL PROTECTED] Talking has been known to lead to communication if practised carelessly.
Re: Annoyances of aptitude
On Fri, Oct 03, 2003 at 02:52:02PM -0400, Daniel Burrows wrote: This is exactly what aptitude does (assuming unwanted means will be removed when nothing depends on it) The strange thing for me is, that aptitude sometimes displays the A letter and in some versions it does not. Have you removed that feature or do I have to turn it on? I used to mark all packages I do not care with that feature. Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: Annoyances of aptitude
On Fri, Oct 03, 2003 at 11:48:13PM +0200, Bernd Eckenfels [EMAIL PROTECTED] was heard to say: On Fri, Oct 03, 2003 at 02:52:02PM -0400, Daniel Burrows wrote: This is exactly what aptitude does (assuming unwanted means will be removed when nothing depends on it) The strange thing for me is, that aptitude sometimes displays the A letter and in some versions it does not. Have you removed that feature or do I have to turn it on? I used to mark all packages I do not care with that feature. I think this has to do with the default display format not always being upgraded. It should be %c%a%M %p #%v%V. Daniel -- / Daniel Burrows [EMAIL PROTECTED] ---\ | I've struggled with reality for thirty-five years, | | but I'm glad to say that I finally won. | | -- _Harvey_ | \-- A duck! -- http://www.python.org -/
Re: Annoyances of aptitude
On Fri, Oct 03, 2003 at 08:20:33PM +0200, Sebastian Kapfer wrote: A minor issue that plagues me as a Sid user is the broken packages display. When I install foo that breaks package bar by conflicts of dependencies of dependencies (you get the idea), aptitude tells me that there are broken packages. That's nice to know, but it would be even better if aptitude could display a _list_ of these packages in the g view (I mean the summary that appears just before committing the changes). With the current release, I have to browse through the packages and hope to stumble on the broken ones. I find the following painful in aptitude: I select package a to install. It suddenly says package x is broken. Why is package x broken? Neither package conflicts with each other. Eventually I find it I manually go up the dependancy tree far enough, package a depends on package b which depends on package c. Package x depends on package y which depends on package z. Package c and z conflict with each other. This could be for a variety of reasons, and more likely to happen if you use apt-pinning to use a mix of packages from stable, testing, and unstable. Or package b depends on package c|d. Package c conflicts with package z, and package d just happens to be broken at that point in time. It would be good if it was possible to visualize complicated conflicts like this in a easier manner, without having to manually work out why each one occurs. I suspect this might be easier said then done. So far every time I have tried to use aptitude, aptitude immediately decides some new packages that I don't want have to be installed and some existing packages that I want to keep need to be removed (even though apt-get is happy with the system as is), and resolving these can be rather complicated and tends to put me off. (sorry I don't have any specific examples right now). -- Brian May [EMAIL PROTECTED]
Re: Annoyances of aptitude
On Sat, Oct 04, 2003 at 10:59:09AM +1000, Brian May wrote: On Fri, Oct 03, 2003 at 08:20:33PM +0200, Sebastian Kapfer wrote: A minor issue that plagues me as a Sid user is the broken packages display. When I install foo that breaks package bar by conflicts of dependencies of dependencies (you get the idea), aptitude tells me that there are broken packages. That's nice to know, but it would be even better if aptitude could display a _list_ of these packages in the g view (I mean the summary that appears just before committing the changes). With the current release, I have to browse through the packages and hope to stumble on the broken ones. I find the following painful in aptitude: I select package a to install. It suddenly says package x is broken. Mostly in aptitude when I see a broken package, I highlight it, hit the + key, and it either works or it's really broken (i.e., something's missing). What aptitude *does* do that bugs me is sometimes packages I install with dpkg -i (such as kernels/modules) will be automagically selected for removal, if I'm not careful to reselect them.
Re: Annoyances of aptitude
On Fri, Oct 03, 2003 at 06:29:19PM -0400, Daniel Burrows wrote: I think this has to do with the default display format not always being upgraded. It should be %c%a%M %p #%v%V. Thanks, indeed. It helped to delete ~root/.aptitude. Didnt know it stores something, there. Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: Annoyances of aptitude (Was: Where are we now?) (Was: Bits from the RM)
As I indicated in a recent message, I don't currently have time to get aptitude working the way I'd like. Please consider this a public call for a codeveloper -- you can interview by submitting working patches for one of the issues below, particularly the ones I've outlined a fix for. (aptitude is maintained as an Alioth project, so if you have an Alioth account, I can just add you to the project) I've added notes on immediate and long-term solutions to some of these issues below, tagged as [development note]. If no-one takes me up on this, which history would indicate is likely, this will make a nice TODO list anyway :) On Thu, Oct 02, 2003 at 07:43:37PM -0400, Nathanael Nerode [EMAIL PROTECTED] was heard to say: Although aptitude uses only one fewer line of screen space for the list of packages, somehow it manages to have less information. The absence of priority information is unpleasant to say the least. Priority information isn't shown because I felt it would clutter up the screen, and I for one never used that information anyway. It will never be visible by default. In trying to get it to show priorities, I discovered that the options for changing display formats are completely cryptic; on my machine I see: The default grouping method for pacakge viewsr) The r) should be a different color than the rest, which is why I've never noticed this on my computer. I suspect you're using a less featureful terminal than standard xterm? [development note] In any event, this table needs some padding between the two columns. This is a fairly simple fix, unless I forgot to implement inter-column padding in vs_table, in which case it needs to be hacked in first. The default display-limit for package views The display format for package views %c%a%M %p #%v%V The display format for the status line%d The display format for the header line%N %n #%B %u %o [development note] This is a nice general method of configuration, but for many tasks something like this would be better: View- Show/Hide column- [X] Action [X] Package name ... An interesting problem would be to merge the two methods of configuration. The current method is much more flexible, but the design makes it hard to reliably configure the columns based on a bunch of boolean variables. A new design or design changemight be needed: for instance, only allow one column of each type (which makes some sense anyway) and store a boolean vector indicating which columns are active. When packages are selected to be installed by default as the result of a manually selected package, I get to see and adjust the list before going ahead with the download install. Unfortunately, I *don't* get to see whether the packages are being selected because they are actually depended upon, or whether they're Recommended, or whether they're Suggested. [development note] Code to determine this is in cmdline.cc. To move it to the UI: (a) move it somewhere under generic/ (b) figure out how to put its output into the preview screen. A reasonable first try is to put it in the lower half of the screen, where the package description is by default. One approach to this is to make the lower half of the screen switchable (using a vs_multiplexer) and to bind some key to switch it. I think this may already be done in order to allow tag databases to be edited. Then, add a new page to the multiplexer which is visible by default and shows extended information about why the currently selected package is in its current state. This infrastructure could also be used to show package info in the lower half like dselect does, eventually (but maybe a modifiable form like the aptitude info screen) See how package descriptions work in the code for more information. There's no easy way to get the dselect behavior of These are recommended, these are suggested. Which do you want? -- which is what I like. [development note] It might be a good idea to add a tree for suggested but not selected packages to the preview screen. This tree should be collapsed by default. Figuring out how to tell aptitude not to automatically delete unused packages required reading the User Manual while knowing that this was an issue. This is on by default, and the information about marking a package manually selected or not does not immediately spring to mind as having anything to do with whether a package is unused or not. Perhaps if it said Remove unused automatically-installed packages automatically ? ;-) In most cases, the garbage collection should operate without you needing to know about it. (the increasing prevalence of meta-packages is making this a bit tricky -- some explicit marking of these beasts in the package tags might be nice) If you have a problem, it's likely because
