Age | Commit message (Collapse) | Author | Files | Lines |
|
'opens' the sections ('admin', 'database', ..., 'x11'), the next level in the tree ('main', 'contrib', 'non-free') appears ordered like that (by its 'importance') rather than alphabetically ('contrib', 'main', ...), as it was done until now. It uses the option 'Aptitude::Sections::Top-Sections' to determine the order at runtime. (Closes: #181997)
|
|
|
|
by using boost::tokenizer, and removing the functionality of sorting policies having parameters (none of the policies admitted parameters for many years)
|
|
The resulting functors:
- pkg_name_lt
- pkg_ptr_lt
- ver_name_lt
- ver_ptr_lt
- dep_type_lt
|
|
|
|
|
|
|
|
|
|
|
|
menu in aptitude-gtk, and remove all references to this menu entry (Closes: #552522)
|
|
it induces to error when reading the code
|
|
|
|
This is intended behaviour according to documentation. Current situation
basically makes priority cost level a no-op and useless.
|
|
* src/ui.cc(really_do_clean, really_do_autoclean): Use "archives" lock.
* src/cmdline/cmdline_clean.cc(cmdline_clean): Remove call to apt_init.
Use "archives" lock instead of system lock.
* (cmdline_autoclean): Use "archives" lock instead of system lock.
|
|
|
|
|
|
The previous list update code is mainly a duplication
of the algorithm available in libapt-pkg. It has a
history of being problematic and was generally never
up-to-date with APT. The new code simply wraps an
algorithm provided by libapt-pkg and resolves some
long-standing issues:
- Update errors are reported. (Closes: #451137)
- Run APT::Update hooks. (Closes: #476399)
The one known short-coming with the new code at the
moment is that if the user cancels the download in
the curses interface, errors are reported for any
files that were remaining.
|
|
|
|
|
|
|
|
* src/solution_dialog.cc (solution_dialog::update): Fix typo
from commit 3616465. Thanks to Hristo Hristov for the patch
(Closes: #552747)
|
|
|
|
Closes: #652419
|
|
Closes: #581597
Closes: #604392
|
|
Closes: #653120
|
|
Closes: #652360
|
|
Hacked for now, this function could use some restructuring to
prevent this kind of thing happening.
Closes: #495046
|
|
Closes: #583201
|
|
|
|
While the intention is admirable, the fact is that this code isn't used and
I don't have time today to use it.
|
|
Specifically, Safe-Upgrade::No-New-Installs and Safe-Upgrade::Show-Resolver-Actions.
These options were documented but have never worked. A quick skim
didn't
turn up any bugs filed about them, so I guess no-one ever tried them.
Removed them.
Also opportunistically cleaned up the documentation of
--new-new-upgrades and --no-new-installes (Closes: #568297).
|
|
|
|
I'm not sure that it's cleaned up correctly right now; need to double back and check this later on.
|
|
|
|
Also fixes a type: EXTRA_DEST -> EXTRA_DIST.
|
|
Should avoid any surprises due to the new "preserve the auto flag" logic,
although I tested with and without this change and both seemed to work OK.
|
|
#622719)
For some reason, MarkInstall likes to clear the auto flag of packages
that the user upgraded manually. This will only affect the "head"
package, so recursive installs still turn packages to automatic mode.
|
|
source package.
Closes: #497206; thanks to Thadeu Lima de Sourza Cascardo for the patch.
Didn't merge the part of the patch that adds an entry to the Views menu,
as I don't personally believe that this grouping needs its own entry
there.
|
|
Should fix all the crashes I know about due to a missing Xapian.
|
|
Also added ?term-prefix to the test suite (oops).
|
|
|
|
Thank you, g++ 4.6 (it includes a new warning about unused local variables).
|
|
g++ 4.6 requires this in order to use offsetof().
|
|
#588089)
The fact that aptitude crashes with ?term when Xapian isn't installed is
also concerning: it should do something "reasonable" instead. But what
made this really painful is that aptitude was generating a term matcher
for a lone tilde, which happens, um, whenever you start typing a search
pattern with incremental search enabled...
|
|
|
|
These never worked out as well as I intended, and all indications
were that they would be a maintenance burden...or just bitrot.
Fully parallel builds are nice, but my builds are pretty quick on
my 8-core box even with the artificial chokepoints that automake
induces.
|
|
Whoever's in charge of libapt these days apparently doesn't believe in
backwards compatibility. Or in documenting how their APIs are to be
used, or why names are deprecated </gripe>
|
|
|
|
set. (Closes: #612034)
Ew ew ew ew ew. Now I have to cut a security update :(
I almost wonder if it's worth just dropping the hierarchy editor
entirely; probably no-one uses it and there are probably more bugs
hiding there (albeit hopefully not security-related).
|
|
Makes it a lot easier to analyze what's going on, at the cost of making
logging more expensive.
Could also cause portability problems if pthread_t is not printable for some
reason (but since it's the return value of a C function, it pretty much has
to be a native integer type).
|