add user extensions
|Deletions are marked like this.||Additions are marked like this.|
|Line 3:||Line 3:|
|The [[BTS]] contains plenty of [[http://bugs.debian.org/src:aptitude|bug reports and feature requests]] to keep any interested contributors occupied. New to FreeSoftware? Try tackling one of the [[qa.debian.org/GiftTag]] bugs listed [[http://email@example.com;tag=gift|here]], and ask for guidance on the mailing list: <<MailTo(firstname.lastname@example.org)>>.||The [[BTS]] contains plenty of [[https://bugs.debian.org/src:aptitude|bug reports and feature requests]] to keep any interested contributors occupied. New to FreeSoftware? Try tackling one of the [[BTS/NewcomerTag|bugs suitable for newcomers]] listed [[https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=aptitude;tag=newcomer|here]], and ask for guidance on the mailing list: <<MailTo(email@example.com)>>.|
This page contains future plans for the Aptitude package manager. If you want to toy with the code and aren't sure where it's going, here's where you look.
The BTS contains plenty of bug reports and feature requests to keep any interested contributors occupied. New to FreeSoftware? Try tackling one of the bugs suitable for newcomers listed here, and ask for guidance on the mailing list: <firstname.lastname@example.org>.
- General (non-packaging) UI Work
- Package List
- Finding Packages
- Dependency resolver
- Package States
- User Extensions
General (non-packaging) UI Work
aptitude's initial slogan was that "just because it's a terminal program doesn't mean it has to be painful". I applied this both to the internals of the program and to its interface; however, time has made it clear that some parts of the interface really fail to live up to this ideal.
Fix the tree code
MVC is our friend
The tree code is very old and klunky. We should probably have a tree store that's separated from the tree view MVC-style (a la GTK, for instance). This would eliminate a lot of the need for crazy subclassing that's currently used and generally make everything more maintainable. It would open the door to stuff like a real implementation of non-hierarchical views, properly sized columns, and dynamically modifiable trees.
The downside is that this is going to be a big and invasive change and will require some design work (watch this space).
Add counts of the number of packages in each section.
This should be a simple change: e.g., "--\ (100) Upgradable Packages". There have been many times that I've wished I had this information available, I just never think of it when I'm coding.
Fix the options dialog
The options dialogs are horrible: they're hard to use, ugly, and scale badly. A much more maintainable approach would be to introduce a new, tree-based toplevel view for examining and modifying the options. I propose a split-pane approach:
+-------------------------------------------------+ + --\ Options | | [X] Display help bar | | [ ] Auto-hide the menu bar | | Search as the user types... | | | | | +-------------------------------------------------+ | Enable this option to display a brief summary | | of several important commands immediately below | | the menu bar. | | | | Corresponds to the configuration value | | Aptitude::UI::HelpBar. | | This option is currently ENABLED. | | | +-------------------------------------------------+
Work on this code should go into an options/ subdirectory of the codebase, to avoid further polluting the root.
Some details need to be worked out; for instance, it might be better to have a column in which the value of each configuration entry appears (so that string and radio entries can also appear there). To edit settings, the user will select them and press Enter; this will toggle Boolean values and pop up an entry dialog for non-Booleans. There should also be a way to reset individual options to their default values.
Implemented 2007-3-21 -- dnb
aptitude upgrade and aptitude dist-upgrade are endlessly confusing to users. I may be stuck with dist-upgrade due to its huge name recognition, but I would like to at least try introducing safe-upgrade and full-upgrade as recommended alternatives, probably emitting warnings when the old names are used. I am inclined to actually make aptitude upgrade a NOP that just spits out an error telling users to use safe-upgrade instead (after a release of Debian containing an aptitude that deprecates it), but I fear the wrath of people who have stuck this in a script somewhere and don't want to change.
Update + Upgrade
Almost everyone seems to follow "aptitude update" with "aptitude dist-upgrade". It might be sensible to add an "aptitude sync" command that would have the effect of update followed by dist-upgrade, to save some typing and database I/O. My main concern here is that people would probably start using it in preference to the other two commands, with the effect of hammering the servers (requesting package indices over and over). I don't know if this is a realistic concern, though.
Confusing changes list
I've had a number of users complain that aptitude's command-line list of actions is confusing. For instance, aptitude lists three sets of removed packages, and it isn't always clear what the relationship between them is. I think it would be better to only show a list of packages that are being installed, a list of packages being upgraded, and a list of packages being removed; the "removed" list should be placed near the prompt so people see it even if there's a lot of scrollback.
In order to convey the additional information (why packages were installed/removed, etc), the following flags could be used:
A - the package is being automatically removed/installed
u - the package was unused and is being removed
p - the package is being purged (this is already used in the current version)
Implemented 2007-3-21 -- dnb
People are periodically confused by the fact that upgradable "new" packages appear only under "new packages". It might be worth breaking the rule that packages appear in only one place, or just cancelling the "new" status of all installed packages (I prefer the first choice).
aptitude's main purpose in life is to allow users to find packages. Given that this is the case, it's a bit surprising that it's so awful at it. Here are some ways that it could be improved.
Search is limit
Most programs these days handle searches by opening a new view that contains the results of the user's search. I think this is eminently sensible and should be considered for adoption in aptitude; at the very least, "limit" should create a cloned view instead of modifying the current view.
Why not eliminate search-in-the-current-list altogether? The main reason to keep it that I know of is that it's sometimes useful to see packages that are in the same section as the package you found and are alphabetically close to it. This is, IMO, more a reflection of aptitude's lousy search capabilities than anything else; if those packages are relevant, they should have been returned by the first query you issued! If aptitude's search capabilities are enhanced as described below, searching should just display a list of magically located useful stuff. (with perhaps the existing limit and search capabilities available as variants)
Search results ordered by popcon
When using limit-style searching, a good way of guessing what the user might want could be to order the results using popcon data.
Readable search terms
aptitude's search terms are mutt-style: ~naptitude, ~Drecommends:aptitude, etc. These are nice and terse, but are also unreadable and unmemorable. I propose extending the query syntax with search terms that use expanded names; for instance, ?name(aptitude) and ?recommends(?name(aptitude)). Since a question mark is a valid regex character, this would mean that you couldn't stick a long-style query next to a short style query: ~naptitude?recommends(aptitude) would look for a package named "aptituderecommends" or "aptitudrecommends".
I think new users tend to search for g++ and wonder why they don't get it. Regexps are great, but I think they should be explicitly marked; for instance, #R(regex).
Smart searching by default
If the user types a string that isn't part of an explicit tilde command, the searcher looks for a package whose name matches that string. It should really look for a package that is 'relevant' to that string. A good first step would be to search both names and short/long descriptions. More intelligent searches based on textual relevance of descriptions and debtags would be great, though.
More efficient searching
For some searches, such as "packages depending on this package", you have no real hope of avoiding a full database search. But we should really be using indexes to perform text searches over the whole archive, even if smart searching isn't implemented.
?DebTags is an effort to manually classify Debian packages. While this has limitations, aptitude could definitely lean on it more than it does.
aptitude should load the binary debtags cache (Debian bug 397652).
- aptitude should use debtags information in searches more aggressively. For instance, textual search could include debtags values.
Better dependency-aware searching
Often people want to do something like "fulfill all recommendations that aren't currently fulfilled". The reverse dependency matcher doesn't help here since there's no way to tell whether a dependency is currently fulfilled (think about ORed dependencies, for instance).
I have two interesting ideas for solving this: (a) make dependencies "first-class values" in the search language, and have "aptitude install" applied to a broken dependency fix it, or (b) just add a new searcher that selects a smart target for a chosen set of broken dependencies. (b) is probably a lot easier, although it would mess up the auto status of packages.
Keeping user selections
At the command-line, aptitude heavily penalizes any change that alters an explicit selection of the user. Two years ago I apparently believed that something dreadful would happen if I did the same thing in visual mode, but nowadays I can't for the life of me think why not. aptitude should weight against changing packages the user has explicitly selected, and against breaking holds.
Handling the null solution
The "null" solution here is a bit of a misnomer: it isn't the empty one, it's the one that reverts all of the user's changes. Aptitude explicitly excludes this solution from consideration. However, my experience is that this confuses users: they wonder why aptitude can't find a solution that exists. Also, I've had reports that aptitude sometimes generates solutions that are supersets of the null solution; and I'm not 100% convinced that it's safe to throw these out.
It might be worth considering an alternative approach. First, adjust weights as I mentioned in "Keeping user selections"; this should heavily disadvantage the null solution. Second, make it clearer when the null solution shows up by abbreviating it in the UI: instead of "do (A and B and C, reverting your changes) and D and E and ...", the UI should say "cancel all your changes and do D and E and ...". I think this would help, because part of the problem with the past situation (aside from users complaining that it was stupid for aptitude to cancel their selections) was that it wasn't always obvious that aptitude would cancel everything (esp. in complicated situations), so people would apply the solution and then wonder why nothing was being done.
I need to start accumulating minimal reproducing examples of places where the dependency resolver used to screw up and no longer does, to get some confidence that it's not making worse decisions now than in the past. Accumulating these examples is a bit tricky: the resolver's behavior is a combination of how aptitude assigns scores and how the resolver acts on those scores, and while the scored dependency problem can easily be extracted, the "assign scores" step is mixed up with the mess that is libapt.
The resolver has too much trouble dealing with situations where it has more than one choice for most packages. Based on traces I've read, it looks like we're doing this:
I need to resolve A -> B1 \/ B2. I enqueue both B1 and B2 as resolvers.
I need to resolve C -> D1 \/ D2. I enqueue both D1 and D2 as resolvers. This lowers my score to the point that I have to back up and try the other B-branch, so now I have 4 branches.
- Repeat until memory or the user's patience is exhausted.
One solution is to make aptitude chase down each branch more aggressively (that is, behave more like a depth-first search). Loïc Minier reports that modestly increasing ?StepScore (to 50 from the default of 10) clears up a knotty dependency problem he ran into. This is a good short-term fix, but is less than ideal, since it could easily decrease the quality of the solutions produced by the resolver.
Another option is to take advantage of the similarities in each branch. In the above example, we get four active search points: B1 /\ D1, B1 /\ D2, B2 /\ D1, and B2 /\ D2. This is equivalent to saying that we're looking for solutions that are extensions of (B1 /\ D1) \/ (B1 /\ D2) \/ (B2 /\ D1) \/ (B2 /\ D2). But this is algebraically equivalent to (B1 \/ B2) /\ (D1 \/ D2)!
In other words: branches are currently represented as conjunctions. Allowing them to be general monotonic Boolean formulas opens up the possibility of representing searches like this, where there are several independent alternatives being chosen from, in linear space instead of exponential. (this is legal as long as their "next moves" are the same; i.e., as long as they have the same sets of broken dependencies/excluded versions and no broken dependency implicates a package version that's inside a disjunction) I expect that this is almost always something we can take advantage of in large searches.
Note: we can do this without losing score information due to the fact that scores are purely additive (changing a solution in a monotonic way has an effect on its score that is independent of the initial solution).
The problem is that I don't know of any general way to minimize monotonic Boolean formulae. In fact, I believe (without being able to come up with a reference ATM) that this is an NP-hard problem in the nonmonotonic case! The monotonic case could be easier (monotonic SAT sure is ), but I haven't been able to track down a reference one way or the other. I think I have a trick that should work in trivial cases, and that might turn out to be enough in practice.
Holds not compatible with other APT frontends
Package holds in aptitude are private and not compatible with other Apt frontends. 137771
AutoInstalled cleared during certain operations
Some operations clear the ?AutoInstalled flag when perhaps they shouldn't. At certain times aptitude was very bad for this, but is much better now. Most remaining cases seem related to ?Aptitude/ProblemResolver. This list of bugs needs to be investigated and resolved.
Ideally, aptitude should have clear and well-defined behaviour, this means that it must be relatively simple and easy to understand. There are always requests for some feature or alternate behaviours that do not really fit with this, or perhaps are useful only in some few situations. For those cases we do not wish to clutter the main program and make it more difficult to maintain, yet still it would be nice to offer those features to users who desire them.
Supporting user extensions in a language such as Scheme, or Python would permit this. Python has an advantage in that it already has bindings for Apt in the python-apt package.
Ideas for extensions
(Mostly collected from the issue tracker.)
Associating various information with packages (beyond what user tags support) 301100
Override or create custom package relationships 341400
Mark some packages to be removed each time aptitude is run (similar to deborphan) 366520
Temporarily install packages 432057
- Create new commands (such as install-without-recommends)
Auto-depend on debugging symbols 600373
Fetch from snapshot.d.o if package unavailable 668876
- Customize parts of the problem resolver
- Customized search patterns
View package bug reports 660958