Age | Commit message (Collapse) | Author |
|
This adds a new "autopurge" command that will is a shortcut for
"autoremove --purge"
Thanks: Michael Vogt for the initial work
|
|
The dpkg frontend lock is a lock dpkg tries to acquire
except if the frontend already acquires it.
This fixes a race condition in the install command where the
dpkg lock is not held for a short period of time between
different dpkg invocations.
For this reason we also define an environment variable
DPKG_FRONTEND_LOCKED for dpkg invocations so dpkg knows
not to try to acquire the frontend lock because it's held
by a parent process.
We can set DPKG_FRONTEND_LOCKED only if the frontend lock
really is held; that is, if our lock count is greater than 0
- otherwise an apt client not using the LockInner family of
functions would run dpkg without the frontend lock set, but
with DPKG_FRONTEND_LOCKED set. Such a process has a weaker
guarantee: Because dpkg would not lock the frontend lock
either, the process is prone to the existing races, and,
more importantly, so is a new style process.
Closes: #869546
[fixups: fix error messages, add public IsLocked() method, and
make {Un,}LockInner return an error on !debSystem]
|
|
Now that --with-source is supported in show we can go a little further
and add the "syntactic sugar" of supporting deb-files on the commandline
directly to give users an alternative to remembering dpkg -I for deb
files & as a bonus apt also works on changes files.
Most of the code churn is actually to deal with cases probably not too
common in reality like mixing packages and deb-files on the commandline
and getting the right order for these multiple records.
Closes: 883206
|
|
The syntax is a bit awkward, but it is the same as for a package name
and introducing another syntax wouldn't really help usability, so with
apt install ./foo.deb/experimental you will get the dependencies of foo
satisfied by your default release, but if this wouldn't satisfy the
version requirements the candidate for this dependency is switched to
the version from the experimental release. The same applies for apt
build-dep ./foo.dsc/stable-backports which was the initial request.
|
|
apt install pkg/release follows versioned dependencies in the candidate
switching if the current candidate does not satisfy the dependency,
so for uniformity the same should be supported in build-dep.
|
|
This allows third-party package managers like snap or flatpak
to hook in and suggest alternatives if packages could not be
found, for example.
This is still highly experimental and the protocol might change
in future versions.
|
|
The code only used to warn when it came into a situation where
something actually had to be forced. Warn directly after parsing
the command-line instead, that's more accurate.
|
|
This makes it easier to see which headers includes what.
The changes were done by running
git grep -l '#\s*include' \
| grep -E '.(cc|h)$' \
| xargs sed -i -E 's/(^\s*)#(\s*)include/\1#\2 include/'
To modify all include lines by adding a space, and then running
./git-clang-format.sh.
|
|
Including cacheiterators.h before pkgcache.h fails because
pkgcache.h depends on cacheiterators.h.
|
|
Showing messages related to downloading in a mode which can't download
is pretty pointless, so instead of trying harder to make it so that
these messages do not trigger just skip them entirely.
That the message triggered here is an artifact of the implementation in
which the download items are finished, while the code expects them to be
still pending – even the in a previous run completely downloaded files.
Closes: 863635
|
|
The mode wasn't working at all if not used together with --fix-missing
which while likely to come in pairs its legal to use standalone.
Regression-in: eb1f04dda07c2b69549ad9fd793cca0e91841b3e
|
|
Again no practical difference, but for consistency a boolean option
should really be accessed via a boolean method rather than an int
especially if you happen to try setting the option to "true" …
Gbp-Dch: Ignore
|
|
Users end up believing that this is a --force mode as -f is common for
that, but apt doesn't have such a mode and --fix-broken is really not
about forcing something but actually trying to fix the breakage which
tends to be the result of a user forcing something on its system via
low-level forced dpkg calls.
Example: The "common" pattern of "dpkg -i ./foo.deb; apt install -f" is
nowadays far better dealt with via "apt install ./foo.deb".
And while at it the two places handing out this suggestion are changed
to use the same strings to avoid needless translation work in the future
and the suggestion uses 'apt' instead of 'apt-get' as this will be run
interactively by a user, so its a good opportunity to showcase what we
can do and will allow us to be more helpful to the user.
Closes: #709092
Thanks: Kristian Glass for initial patch!
|
|
In effect this is an extension of the 6 years old commit
a8dfff90aa740889eb99d00fde5d70908d9fd88a which uses the autoremover to
remove packages again from the solution which are no longer needed to be
there. Commonly these are dependencies of packages we end up not
installed due to problem resolver decisions. Slightly less common is
the situation we deal with here: a package which we wanted to upgrade
sporting a new dependency, but ended up holding back.
The problem is that all versions of an installed reverse dependencies can
bring back a "garbage" package – we need to do this as there is
nothing inherently wrong in having garbage packages installed or upgrade
them, which itself would have garbage dependencies, so just blindly
killing all new garbage packages would prevent the upgrade (and actually
generate errors). What we should be doing is looking only at the version
we will have on the system, disregarding all old/new reverse dependencies.
Reported-By: Stuart Prescott (themill) on IRC
|
|
Commit b60c8a89c281f2bb945d426d2215cbf8f5760738 improved the situation,
but due to inconsistency mostly for planners, not for solvers. As the
idea of hiding errors if we show another error is a bit scary (as the
extern error might be a followup of our intern error, rather than the
reason for our intern error as it is at the moment) we don't discard the
errors, but if we got an extern error we show them directly removing
them from the error list at the end of the run – that list will contain
the extern error which hopefully gives us the best of both worlds.
The problem itself is the same as before: The externals exiting before
apt is done talking to them.
Reported-By: Johannes 'josch' Schauer on IRC
|
|
We support installing ./foo.deb (and ./foo.dsc for source) for a while
now, but it can be a bit clunky to work with those directly if you e.g.
build packages locally in a 'central' build-area.
The changes files also include hashsums and can be signed, so this can
also be considered an enhancement in terms of security as a user "just"
has to verify the signature on the changes file then rather than
checking all deb files individually in these manual installation
procedures.
|
|
It is a try as the we need to inspect SUDO_COMMAND which could be
anything – apt, apt-get, in /usr/bin, in a $DPKG_ROOT "chroot", build
from source, aliases, …
The best we can do is look if the SHELL variable is equal to the
SUDO_COMMAND which would mean a shell was invoked. That isn't fail-safe
if different shells are involved as sub-shells have the tendency of not
overriding the SHELL so a bash started from within zsh can happily
pretend to be still zsh, so we could have a look at /etc/shells for a
list, but oh well, we have to stop somewhere I guess.
This sudo-prefixing feature is a gimmick after all.
Closes: 825742
|
|
Setting the C++ locale via std::locale::global(std::locale("")); which
would otherwise default to the default C locale (aka: unaffected by
setlocale) effects the formatting of numeric types in IO streams, which
for output for humans is perfectly sensible, but breaks our many text
interfaces used and parsed by us and others without expecting the
numbers to be formatted.
Closes: #825396
|
|
The code moving in eb1f04dda07c2b69549ad9fd793cca0e91841b3e
moved the acquire stuff above the simulation exit, so before getting
locks (and creating/chmod directories) we should be checking if we
should actually really do it…
[ignore as bugfix of an unreleased commit]
Git-Dch: Ignore
|
|
This commit moves the creation of the fetcher and with it the
calculation of the filenames before the code generation the various
lists detailing the solution. This means that simulation comes even so
slightly closer to a real run as it will require and parse the package
indexes for filenames and queuing of URIs, so that a simulation "using"
an unavailable download method actually fails now.
The real benefit of this change is through that the rather special but
nontheless handy --no-download --fix-missing mode now actually shows
what the solution is it will apply to the system rather than the
solution it would if it could download all not-downloaded packages.
|
|
Errors cause a kind of automatic no already, but warnings and notices
are only displayed at the end of the apt execution even through they
could effect the choice of saying yes/no to questions: E.g. if a
configuration (file) was ignored you wanted to have an effect or if an
external solver you used generated warnings suggesting that the solution
might be valid, but bogus non-the-less and similar things.
Note that this only moves those messages up to the question if the
answer is interactive – not if e.g. -y is used or no question is asked at
all so this has an effect only on interactive usage of apt(-get), not
script who might be parsing apt output.
|
|
The old prettyprinters have only access to the struct they pretty print,
which isn't enough usually as we want to know for a package also a bit
of state information like which version is the candidate.
We therefore need to pull the DepCache into context and hence use a
temporary struct which is printed instead of the iterator itself.
|
|
build-dep was implemented by parsing the build-dependencies of a package
and figuring out which packages to install/remove based on this. That
means that for the first level of dependencies build-dep was
implementing its very own resolver with all the benefits (aka: bugs)
this gives us for not using the existing resolver for all levels.
Making this work involves generating a dummy binary package with fitting
Depends and Conflicts and as we can't create them out of thin air the
cache generation needs to be involved so we end up writing a Packages
file which we want to parse – after we have parsed the other Packages
files already. With .dsc/.deb files we could add them before we started
parsing anything.
With a bit of care we can avoid generating too much data we have to
throw away again (as many parts assume that e.g. the count of packages
doesn't change midair), so that on a speed front there shouldn't be
much of a difference, but output can be slightly confusing as if we have
a completely valid cache on disk the "Reading package lists... Done" is
printed two times – but apt is pretty quick about it in that case.
Closes: #137560, #444930, #489911, #583914, #728317, #812173
|
|
This option controls if downloaded packages should be kept after
a successful install or if they should be deleted. The default
for "apt-get" is that they are kept (just like before).
However the default for "apt" is that they get deleted.
Closes: #160743
|
|
Reported-By: cppcheck
Git-Dch: Ignore
|
|
-q is for logging and -qqq (old -qq) basically kills every output expect
errors, so there should be a way of declaring a middleground in which
the output of e.g. 'update' isn't as verbose, but still shows some
things. The test framework was actually making use of by accident as it
ignored the quiet level in output setup for apt before.
Eventually we should figure out some better quiet levels for all tools…
|
|
The bugreport is more conservative in asking for a conditional, but
given that this is a message intended to be read by users to be run by
users we should suggest using a command intended to be used by users.
And while we are at, add sudo to the message – conditional of course.
Closes: 801571
|
|
The main part is refactoring through to allow hiding the magic needed to
support .deb files in deeper layers of libapt so that frontends have
less exposure to Debian specific classes like debDebPkgFileIndex.
|
|
In private-install.cc we call MarkInstall with FromUser=true, which sets
the bit accordingly, but while applying the EDSP solution we call mark
install on all packages with FromUser=false, so MarkInstall believes
this install is an automatic one and sets it to auto – so that a new package
which is explicitely installed via an external solver is marked as auto
and is hence also up for garbage collection in a following call.
Ideally MarkInstall wouldn't reset it, but the detection is hard to do
without regressing in other cases – and ideally ideally MarkInstall
wouldn't deal with the autobit at all – so we work around this on the
calling side for now.
|
|
This ensures that we can install .deb files that are not the
candidate for a given package.
|
|
This breaks the translation for no big gain, but we broke enough strings
already for that to not really matter anymore.
Closes: #82430
|
|
Also do it unconditionally, as it does not hurt.
Closes: #315149
|
|
Some people type them instead of autoremove and autoclean, so make
them happy.
Closes: #274159
Makes-Happy: Ansgar
|
|
This enables more fine grained control over such exceptions.
|
|
Switch to std::unique_ptr, as this is safer than SPtr.
|
|
Sources are usually defined in sources.list (and co) and are pretty
stable, but once in a while a frontend might want to add an additional
"source" like a local .deb file to install this package (No support for
'real' sources being added this way as this is a multistep process).
We had a hack in place to allow apt-get and apt to pull this of for a
short while now, but other frontends are either left in the cold by this
and/or the code for it looks dirty with FIXMEs plastering it and has on
top of this also some problems (like including these 'volatile' sources
in the srcpkgcache.bin file).
So the biggest part in this commit is actually the rewrite of the cache
generation as it is now potentially a three step process. The biggest
problem with adding support now through is that this makes a bunch of
previously mostly unusable by externs and therefore hidden classes
public, so a bit of further tuneing on this now public API is in order…
|
|
We aren't and we will not be really compatible again with the previous
stable abi, so lets drop these markers (which never made it into a
released version) for good as they have outlived their intend already.
Git-Dch: Ignore
|
|
Further abstracting our new ShowList allows to use it for containers of
strings as well giving us the option to implement an or-groups display
for the recommends and suggests lists which is a nice trick given that
it also helps with migrating the last remaining other cases of old
ShowList.
|
|
apt-get is displaying various lists of package names, which until now it
was building as a string before passing it to ShowList, which inserted
linebreaks at fitting points and showed a title if needed, but it never
really understood what it was working with. With the help of C++11 the
new generic knows not only what it works with, but generates the list on
the fly rather than asking for it and potentially discarding parts of
the input (= the non-default verbose display). It also doubles as a test
for how usable the CacheSets are with C++11.
(Not all callers are adapted yet.)
Git-Dch: Ignore
|
|
The "problem" is mostly in the erase() definitions as they slightly
conflict and in pre-c++11 are not uniformly in different containers.
By differenciating based on the standard we can provide erase() methods
for both standards – and as the method is in a template and inline we
don't need to worry about symbols here.
The rest is adding wrappings for the new forward_list and unordered_set
containers and correcting our iterators to use the same trait as the
iterator they are wrapping instead of having all of them be simple
forward iterators. This allows the use of specialized algorithms which
are picked based on iterator_traits and implementing them all is simple
to do as we can declare all methods easily and only if they are called
they will generate errors (if the underlying iterator doesn't support
these).
Git-Dch: Ignore
|
|
This isn't testing much of the 'complex' parts,
but its better than nothing for now.
Git-Dch: Ignore
|
|
Git-Dch: Ignore
|
|
We are checking the space requirements for ages, but the check uses the
free blocks count, which includes the blocks reserved for usage by root.
Now that we use an unprivileged user it has no access to these blocks
anymore – and more importantly these blocks are a reserve, they
shouldn't be used by apt without special encouragement by the user as it
would be bad to have dpkg run out of diskspace and maintainerscripts
like man-db skip certain actions if not enough space is available
freely.
|
|
Reworks the API involved in creating and setting up the fetcher to be a
bit more pleasent to look at and work with as e.g. an empty string for
no lock isn't very nice. With the lock we can also stop creating all our
partial directories "just in case". This way we can also be a bit more
aggressive with the partial directory itself as with a lock, we know we
will gone need it.
|
|
Git-Dch: Ignore
|
|
The comment above their definition marks them already as such, so this
is only a formalisation of the deprecation and fixes the occurances we
have in our own code together with removing a magic number.
Git-Dch: Ignore
|
|
Previously, we had a start and a done of the calculation printed by
higher-level code, but this got intermixed by progress reporting from an
external solver or the output of autoremove code…
The higherlevel code is now only responsible for instantiating a
progress object of its choosing (if it wants progress after all) and the
rest will be handled by the upgrade code. Either it is used to show the
progress of the external solver or the internal solver will give some
hints about its overall progress. The later isn't really a proper
progress as it will jump forward after each substep, but that is at
least a bit better than before without any progress indication.
Fixes also the 'strange' non-display of this progress line in -q=1, while
all others are shown, which is reflected by all testcase changes.
|
|
Conflicts:
apt-private/private-install.cc
|
|
|
|
Conflicts:
debian/changelog
|