| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Closes: #680333
|
|
These should rather be in libapt-pkg but too late for Wheezy.
* generic/apt/dpkg.{cc,h}:
- dpkg_base_args: base arguments for dpkg from APT conf
- dpkg_mult_arch: true if dpkg is multi-arch aware
- dpkg_package_name: returns the name that dpkg uses for
a package
|
|
Closes: #681021
|
|
|
|
Closes: #679602
|
|
.. but fall back to Packages files if the database is not available.
|
|
The behaviour of the non-ept interface has been updated
and corrected, so that, for example, the debtags browser
works correctly.
|
|
|
|
Part of the process to drop libept (see bug #677551):
In src/generic/apt/matching/match.cc there's already
#ifdefs to do everything via libxapian. The only ept-only
bit is ept::axi::path_db(). That can be replaced with
"/var/lib/apt-xapian-index/index", which is the standard
index location which is NOT going to change (that's
actually a xapian pointer to the real index location: try
"cat /var/lib/apt-xapian-index/index").
Also add configure check for libxapian headers.
|
|
The tree included several checks for various ways
that libept previously did things. These old
code paths have been dropped along with the checks
for them.
configure now also supports --disable-ept to build
without using the ept library.
|
|
|
|
|
|
|
|
Contruct a changelog file path for third party sites that
do not use packages.debian.org/changelogs
This simply uses the ArchiveURI() of the source pkg and
looks for a .changelog file there.
LP: #563155
|
|
* src/generic/apt/pkg_changelog.cc:
- use up-to-date changelog uri construction from apt-get
using APT::Changelogs::Server
* src/apt_options.cc:
- drop disused Aptitude::Changelog-URL-Template
* src/cmdline/cmdline_changelog.cc:
- remove extraneous guess-work with source packages,
which happened to also download the wrong changelog
sometimes (Closes: #631464)
- changelog download works with no deb-src lines, so
we don't need to instruct the user to add any
(Closes: #587775, #537393)
|
|
|
|
* [cmdline]: Package arguments without an arch-qualifier
will also consider foreign-arch packages, in
order of preference. (LP: #892074)
* [cmdline]: Package arguments can use '*' wildcard in their
arch-qualifier to select all matching packages,
where 'any' would select only the first such
package.
LP: #892074
|
|
See Debian Policy § 11.1 for more info.
|
|
|
|
When a package is not available or fails to download
incorrectly aptitude would try to continue without it.
This made it hard to detect errors automatically using
the exit status.
This behaviour is no longer the default, instead if there
are missing packages an error will be displayed and the
program exit with failure (100). If the user wishes to
continue anyway, they can use --fix-missing or configure
Aptitude::CmdLine::Fix-Missing in apt.conf.
* [cmdline]: An install run will no longer proceed if any
package was unavailable or failed to download
correctly, instead an error will be shown
and exit with non-zero status (100).
(Closes: #121313, #302784)
The old behaviour can be obtained with the new
--fix-missing option or setting
Aptitude::CmdLine::Fix-Missing.
Closes: #121313
Closes: #302784
|
|
Error conditions are much stricter, detecting errors is more
reliable, and the exit status of all command-line actions is
well-defined.
All commands will return one of these values as their exit
status:
0 – success
1 – user aborted (install, remove, …); or
no matches (search, why, why-not);
100 – failure
For commands whose arguments are lists of packages or search
patterns the following general conditions hold:
It is a failure if any package argument does not exactly
name a package.
It is a failure if any versioned argument requests a
version which is not available for every package
identified by that argument. Versioned arguments are
those which end with a version or archive (release)
specifier, respectively “=<version>” and “/<archive>”.
If a command includes a request to install, remove, or
purge any package that command will not proceed if any
of the above failures occur. Other commands may still
proceed in case of such failures but will exit with
non-zero status to indicate they were not completely
effective.
Some commands have exceptions and/or extensions to the
general conditions:
install, upgrade, remove, …:
Where a request specifies a virtual package it is a
failure if it has either no provider or multiple
providers. If there is only one provider that package
will be selected instead of the virtual package.
search:
All arguments are considered patterns. Arguments
without an explicit search term will be wrapped in an
implicit ‘?name’ term.
This is a major change from previous versions where the
program would have proceeded and possibly exited with a
status indicating success (0) despite some requested actions
being either invalid or ineffective. The new, stricter
behaviour is desirable for two reasons:
- to prevent the situation where a request to replace one
set of packages with another set proceeds when (some of)
the replacements are not found or unavailable could cause
the undesired removal of arbitrary other packages;
- to make the program more atomic and reliable when used for
automated tasks – by considering the entire request as
being essential to success another program can rely on an
exit status of 0 to mean that the request was completely
carried out.
Summary of changes:
* Most errors are now displayed at the end of a command's
output which makes them easier to spot when there is
lots of output. (Closes: #430392)
* [cmdline]: Virtual packages which have an already
installed provider are only skipped when the
requested action is to install them.
* [cmdline]: install and similar actions have much
stronger error checking and will exit more
reliably with non-zero status on failures
Failures which result in no action and a
non-zero exit status (100):
- a package argument does not exactly name
an available package;
- a versioned argument requests a version
which is not available for every package
it applies to (Closes: #590686);
* [cmdline]: changelog exits with non-zero status on any
error (Closes: #675833)
* [cmdline]: search exit with status 1 if it found no
matches (Closes: #497299)
* [cmdline]: why exits with status 1 if it found no
reasons given the particular arguments
* [cmdline]: show will exit with status 100 if it found
no packages or a named package was not found
* unknown arguments do not show the usage screen
* more errors are reported using GlobalError
* clean up some strings used as error messages
* download_install_manager.cc:
- repeat if package manager result is DoAgain;
- report all download errors not just the first;
* cmdline_util.cc:
- pkgset_from_string by default is no longer an error if
a pattern matches no packages
* [doc]: add section on exit status to the man page
Closes: #430392
Closes: #497299
Closes: #590686
Closes: #675833
|
|
Previously aptitude was using it's own command line
parser implemented on top of getopt. Replacing this
with the standard apt class means there are no longer
subtle quirks with our parser (such as "-qq" not
being valid, when it is fine for other apt programs).
The parser is closely tied to the Configuration, and
reads options directly in to the global apt config.
Some options were tracked independently of the global
config; this change is the first part rectifying that
situation. The goal is to keep all program options,
configuration state, etc. in the global config rather
than passing state variables between functions. Many
options which previously did not have an associated
configuration item now do; some remain undocumented
for now as they are transitional.
* handle "-qq" like other apt-utils
* properly process all -o command line options (Closes: #587671)
* unknown command line options trigger an error (Closes: #434502)
* --add-user-tag-to, --remove-user-tag-from are working;
no bug reports suggests that noone has noticed they
were broken
New aliases for some command-line options:
--yes, for --assume-yes (apt-get)
--default-release, for --target-release (apt-utils)
--install-on-startup, for -i
--update-on-startup, for -u
New configuration item:
Aptitude::CmdLine::Sorting, equivalent to --sort
Other new configuration items are for internal use only
at this point.
Closes: #587671
Closes: #434502
|
|
|
|
|
|
|
|
Apt-utils treat regex strings as a search pattern, we should
too.
|
|
Ported some code from apt cacheset.cc to populate a pkgset.
The function pkgset_from_string will fill a given pkgset with
either the exactly named package, or the packages matched by a
string predicated by is_pattern.
In the future, we should look to directly use the apt cacheset
infrastructure. This is currently blocked by our custom
implementation of pkgCacheFile (see aptcache.h).
Errors that occur in looking up the package (such as no package
with that name, or an invalid search pattern) are pushed to
the global error list with a customizable error_type (default:
ERROR).
|
|
typedef vector<pair<PkgIterator,ref_ptr<structural_match> > > pkg_results_list;
typedef vector<pair<VerIterator,ref_ptr<structural_match> > > ver_results_list;
|
|
|
|
Previously, undo incorrectly restored the candidate
to be currently installed version. Keep did not
restore it at all.
Closes: #529403
|
|
Closes: #595753
|
|
Task packages (introduced with tasksel 3.0) are
meta-packages which define the dependencies of tasks. The
packages themselves have always worked but the 'tasks'
grouping policy and '?task' search term did not support
them. This update corrects for this.
As a result of this change to tasksel all Debian tasks now
function exactly like meta-packages. (Closes: #382631)
The syntax for installing tasks from the command line has
been updated. It now supports specifying an arch and
requires the same syntax as apt-utils ('^' must be the last
part of the name). Examples:
# aptitude install gnome-desktop^
# aptitude install ssh-server^:armel
This avoids ambiguity that may arise when a task and
package have the same name.
Closes: #382631
|
|
Task packages (introduced with tasksel 3.0) are
meta-packages which define the dependencies of tasks. The
packages themselves have always worked but the 'tasks'
grouping policy and '?task' search term did not support
them. This update corrects for this.
As a result of this change to tasksel all Debian tasks now
function exactly like meta-packages. (Closes: #382631)
The syntax for installing tasks from the command line has
been updated. It now supports specifying an arch and
requires the same syntax as apt-utils ('^' must be the last
part of the name). Examples:
# aptitude install gnome-desktop^
# aptitude install ssh-server^:armel
This avoids ambiguity that may arise when a task and
package have the same name.
Closes: #382631
|
|
|
|
|
|
This follows recent changes in apt which added support for
files greater than several gigabytes in size -- using the
'unsigned long long' type to store the file size.
Changelog download is restored as a result of this.
Closes: #669569
LP: #824708
|
|
|
|
Previously it would apply that limit if UI::Preview-Limit was not set.
This was causing confusion and it is more useful to have these as two
clearly distinct settings.
LP: #381507
|
|
Closes: #654344
|
|
Other tasks which access that directory (such as 'apt-get
clean') will now fail if aptitude is downloading or
installing packages. (Closes: #370381)
|
|
|
|
Previous code did not hold it for the full download.
Closes: #653479
|
|
|
|
LP: #972847
|
|
This was a rather unsightly kludge and is better suited as
a script for APT::Update::Post-Invoke.
|
|
* src/generic/apt/download_update_manager.cc:
- run APT::Update hooks (Closes: #476399)
- report fetch errors (Closes: #451137)
|
|
This reverts commit bd3f0ed4935577f5d942b418f11c0a8a50894c7b.
ListUpdate did not fit download_upload_manager well, but appeared
to work. Now reverting in favour of updating the local code and
hopefully this allows us to tackle some of the bugs that popped up.
|
|
|
|
Closes: #670379
|
|
|
