Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
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
|
|
|
|
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
|
|
|
|
|
|
|
|
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;
|
|
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
|
|
LP: #972847
|
|
Closes: #670379
|
|
|
|
A search pattern with no explicit term, "s", is equivalent to
"?name(s)". This changes modifies these semantics when the
pattern is arch-qualified, "name:arch" which is now equivalent
to "?exact-name(name) ?architecture(arch)".
These are the semantics used by apt-get and others which are
internally derived from pkgCache::FindPkg("name:arch").
On the command-line, it is possible to specify both an architecture
and an archive/version, as well as an override specifier:
# aptitude install an:armel/sid tf:armel-
* src/generic/apt/matching/parse.cc:
- extended semantics as per above.
* src/cmdline/cmdline_versions.cc:
- modify argument processing to use the extended semantics.
|
|
Thanks: Colin Watson
Thanks: Michael Vogt
Closes: #497539
|
|
|
|
'deptype' is now used consistently to indicate direct use of
pkgCache::Dep::DepType as opposed to pkgCache::Dep.
* src/generic/apt/apt.h (deptype_lt): also condense a trivial switch
statement.
|
|
Dependencies on Arch: all packages are still handling incorrectly.
This patch thoroughly exposes this issue in the curses interface.
Where previously aptitude would show (aboot-cross:amd64 info):
--\ Depends (2)
--- aboot-base (UNAVAILABLE)
which is incorrect (as aboot-base *is* available), we now see:
--\ Depends (2)
--- aboot-base:amd64 (UNAVAILABLE)
which makes it clear why the package is *considered* unavailable.
APT tools (at least, 0.8.15 series) exhibit this same problem
when displaying dependencies.
Exposing this issue enables improvements to the dependency
parser/handling to be made.
Non-multi-arch systems are unaffected.
|
|
|
|
|
|
|
|
* src/generic/apt/apt.{cc,h}:
- New function multiarch_type returns a string describing
a multi-arch type.
* src/cmdline/cmdline_show.cc, src/pkg_info_screen.cc:
- Show Multi-Arch field on packages where this is set.
|
|
|
|
|
|
|
|
The resulting functors:
- pkg_name_lt
- pkg_ptr_lt
- ver_name_lt
- ver_ptr_lt
- dep_type_lt
|
|
|
|
|
|
|
|
* 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.
|
|
|
|
|
|
Closes: #652419
|
|
Hacked for now, this function could use some restructuring to
prevent this kind of thing happening.
Closes: #495046
|
|
Also fixes a type: EXTRA_DEST -> EXTRA_DIST.
|
|
|
|
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>
|
|
Also documented this new behavior and wrote a unit test for it.
|
|
It's really just a hack to break the command-line implementation up in a
way that's more amenable to unit-testing; it doesn't belong in the generic
view interface.
|
|
downloads and delete acqprogress.
|
|
because it's already downloaded.
|