| Age | Commit message (Collapse) | Author |
|---|
|
If we have a user sitting around we can let 'apt' ask the user for a
confirmation rather than print errors at the end and require the user to
figure out which commandline flags are needed to confirm the changes
non-interactively.
|
|
The value of Origin, Label, Codename and co can be used in user
configuration from apts own pinning to unattended upgrades.
A repository changing this values can therefore have serious effects on
the behaviour of apt and other tools using these values.
In a first step we will generate error messages for these changes now
explaining the need for explicit confirmation and provide config options
and commandline flags to accept them.
|
|
The exception was made to give (script) users a one-release grace period
to adapt their setup to deal with apt enforcing signing of repositories.
As we are now at the start of a new release cycle its as good a time as
any to lift it now.
Removes-Exception: 952ee63b0af14a534c0aca00c11d1a99be6b22b2
|
|
Adopting this change in other frontends will require source changes as
well similar to our own changes in apt-private/.
|
|
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
|
|
We are in a dilemma here: The regression of sorts was introduced in 2013
with commit d8a8f9d7f0 allowing pkg modifiers for the upgrade commands.
That calls the autoremover as a sideeffect through and with it comes the
option to remove the garbage packages in these commands (similar to aptitude).
Having the option on the commandline is no problem – people aren't going
to request what they don't want (or so I hope), but the documentation
explicitly states that this option only effects install/remove and
mentions a config knob users might use and expect to not suddenly apply
(especially without documentation) to more commands.
Just reverting the commit is out of question, completely ignoring the
option breaks the workflow of every user who happened to use
--autoremove on the commandline for upgrade and expects that to work
given that it was accepted and worked in a stable release. Changing the
documentation to reflect reality while perhaps the simplest and cleanest
option contradicts freeze and is a surprising change we tend to avoid
like the plague while just leaving it be confuses all users who end up
believing the documentation even if was different in the last 3 years.
So what we do is a tricky compromise: The configuration option if read
from a file does apply only for install/remove as documented, while if
the option is encountered on the commandline it is accepted and applies
to the upgrade which should make 99% of the users happy. The rest has to
wait for us to figure out for buster how to get that documented and
implemented in a saner way.
Closes: #855891
|
|
Most of them in (old) code comments. The two instances of user visible
string changes the po files of the manpages are fixed up as well.
Gbp-Dch: Ignore
Reported-By: spellintian
|
|
Normal cows moo every time they feel like it and it might be a "moo",
"moo!" or "moo?". This is completely unacceptable behaviour in our super
cow through as as a superior being it has to show its superiority over
the common cows and the meager easter eggs by being fully reproducible!
The second version of Chris' patch is modified to include an array of
tests for this feature – which doubles as explanation for some of the
moo lines by giving more exact dates – and falling back to current time
if the environment is invalid + passing time around instead of having an
invalid environment be an unrecoverable error (aka: Guru Meditation) as
that is more inline with how apt usually behaves: The wisdom of super cow
should be available to everyone, even to the most misfortune users not
capable of having a valid environment variable.
That makes the code slightly more ugly, so instead of requiring a young
follower to produce a third version a high priest of the cult applied the
finishing touches as he is used to the pain by now – and another round
with the slowpoke high priest would have been a serious threat to the
Debian release schedule which the cow would not approve.
Closes: #848721
Signed-off-by: Super Cow
Thanks: Chris Lamb for initial patch and guru meditation
|
|
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
|
|
The update command acquires a lock on lists/, but at the end it will
also require the dpkg/lock while building the binary caches. That seems
rather pointless as we are only reading those files, not causing writing
in them. This can also cause problems if a package installation is
running and a background process (like cron) starts an update: If you
are "lucky" enough the update process will pick the dpkg lock in between
apt calls causing the installation process to fail.
|
|
We get the archives/lock for clean – that is enough to ensure that other
apt instances aren't interfering (or are being interfered with). We
don't need to block actions involving dpkg.
|
|
Unlikely that anyone is actually running into this, but if we asked to
not generate a cache and avoid it in the first step we shouldn't create
one implicitly anyway by displaying the statistics.
|
|
This will avoid people from thinking that they have to do nothing
when they change the set of files.
Gbp-Dch: ignore
|
|
The idea is simple: Each¹ Find*( call starts with a call check if the
given option (with the requested type) exists in the whitelist. The
whitelist is specified via our configure-index file so that we have
a better chance at keeping it current. the whitelist is loaded via a
special (undocumented for now) configuration stanza and if none is
loaded the empty whitelist will make it so that no warnings are shown.
Much needs to be done still, but that is as good a time as any to take a
snapshot of the current state and release it into the wild given that it
found some bugs already and has no practical effect on users.
¹ not all in this iteration, but many
|
|
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!
|
|
The config list APT::Build-Essential gets a similar treatment to other
lists now by having the value of the option itself be an override for
the list allowing to disable build-essentials entirely as well as
adding/overriding as usual by now in other lists.
Reported-By: Johannes 'josch' Schauer on IRC
|
|
The implementation is quite different compared to --arch-only due to ABI
reasons but functionality wise they are similar and usually both
available for symmetry at least.
Closes: #845775
|
|
In bug #757534 the opposite direction was initially requested, but what
we did end up with was having a possibility to configure the options
passed to dpkg. The reasoning given their and in #724744 is specific why
apt doesn't need the checks to be performed by dpkg. In fact, what these
two reports show is that if those checks are run people end up being
confused about the requirement of them being run, so given the best case
those checks can do is do nothing (visibly) while the worst cases are
warnings and errors which are neither we are from a security point
better of with disabling them – as (as mentioned in the bugreports)
false positives for issues are really really bad in a security context.
Closes: 724744
|
|
We are calling system() in this code paths, so all we do here is having
a single child performing the action while the parent waits for it to
finish… with the added strangeness of not having our usual error message
collection and giving up after first failure even if told to act on
multiple packages.
|
|
That was the case already for tar-only and diff-only, but in a more
confusing way and without a message while dsc "worked" before resulting
in a dpkg-source error shortly after as tar/diff files aren't available…
|
|
These new enum values might cause "interesting" behaviour in tools not
expecting them – like an old apt would think a Build-Conflicts-Arch is
some sort of Build-Depends – but that can't reasonably be avoided and
effects only packages using B-D/C-A so if there is any breakage the
tools can easily be adapted.
The APT_PKG_RELEASE number is increased so that libapt users can detect
the availability of these new enum fields via:
#if APT_PKG_ABI > 500 || (APT_PKG_ABI == 500 && APT_PKG_RELEASE >= 1)
Closes: #837395
|
|
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
|
|
|
|
I probably missed that when I did the usability work. But better
late than never.
|
|
On FreeBSD, we have to include sys/params.h and sys/mount.h,
not sys/vfs.h.
Gbp-Dch: ignore
|
|
Several modules use std::array without including the
array header. Bad modules.
Some modules use STDOUT_FILENO and friends, or close()
without including unistd.h, where they are defined.
One module also uses WIFEXITED() without including
sys/wait.h.
Finally, environ is not specified to be defined in unistd.h. We
are required to define it ourselves according to POSIX, so let's
do that.
|
|
We support "./foobar.deb" as a way to install a deb file directly.
Recently .changes files were added. This highlights a problem as you
can't add the changes file without also trying to install all of them.
Now, it could also be handy to add entire Packages/Sources files to
perhaps get a bunch of packages in without installing them all
implicitly.
This commit introduces --with-source which allows to add *.deb, *.changes,
*.dsc, source-dirs, Packages & Sources files (the later can also be
compressed) without also installing them.
|
|
Bye, bye, old friend.
|
|
This causes build failures when turning translations off.
|
|
Introduce an initial CMake buildsystem. This build system can build
a fully working apt system without translation or documentation.
The FindBerkelyDB module is from kdelibs, with some small adjustements
to also look in db5 directories.
Initial work on this CMake build system started in 2009, and was
resumed in August 2016.
|
|
While autotools defines all macros to 1 explicitly, CMake only
defines them without a value. In such a case, #if fails with an
error and #ifdef works.
In preparation for a possible switch to CMake and to clean up
the code (rest uses #ifdef), use #ifdef here
|
|
Followup of b58e2c7c56b1416a343e81f9f80cb1f02c128e25.
Still a regression of sorts of 8b79c94af7f7cf2e5e5342294bc6e5a908cacabf.
Closes: 832044
|
|
If the sources file we want to edit doesn't exist yet GetLock will
create it with 640, which for a generic lockfile might be okay, but as
this is a sources file more relaxed permissions are in order – and
actually required as it wont be readable for unprivileged users causing
warnings/errors in apt calls.
Reported-By: J. Theede (musca) on IRC
|
|
After editing the sources it is a good idea to (re)built the caches as
they will be out-of-date and doing so helps in reporting higherlevel
errors like duplicates sources.list entries, too, instead of just
general parsing errors as before.
|
|
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.
|
|
Julian noticed on IRC that I fall victim to a lovely false friend by
calling referring to a 'planer' all the time even through these are
machines to e.g. remove splinters from woodwork ("make stuff plane").
The term I meant is written in german in this way (= with a single n)
but in english there are two, aka: 'planner'.
As that is unreleased code switching all instances without any
transitional provisions. Also the reason why its skipped in changelog.
Thanks: Julian Andres Klode
Gbp-Dch: Ignore
|
|
Testing the current implementation can benefit from being able to be
feed an EIPP request and produce a fully compliant response. It is also
a great test for EIPP in general.
|
|
The very first step in introducing the "external installation planer
protocol" (short: EIPP) as part of my GSoC2016 project.
The description reads: APT-based tools like apt-get, aptitude, synaptic,
… work with the user to figure out how their system should look like
after they are done installing/removing packages and their dependencies.
The actual installation/removal of packages is done by dpkg with the
constrain that dependencies must be fulfilled at any point in time (e.g.
to run maintainer scripts).
Historically APT has a super micro-management approach to this task
which hasn't aged that well over the years mostly ignoring changes in
dpkg and growing into an unmaintainable mess hardly anyone can debug and
everyone fears to touch – especially as more and more requirements are
tacked onto it like handling cycles and triggers, dealing with
"important" packages first, package sources on removable media, touch
minimal groups to be able to interrupt the process if needed (e.g.
unattended-upgrades) which not only sky-rocket complexity but also can
be mutually exclusive as you e.g. can't have minimal groups and minimal
trigger executions at the same time.
|
|
Closes: 825216
|
|
Weak had no dedicated option before and Insecure and Downgrade were both
global options, which given the effect they all have on security is
rather bad. Setting them for individual repositories only isn't great
but at least slightly better and also more consistent with other
settings for repositories.
|
|
If apt decides it can't download a file it is relatively pointless to
try to tell dpkg-source to unpack it.
|
|
With this commit all APT-based clients default to refusing to work with
unsigned or otherwise insufficently secured repositories. In terms of
apt and apt-get this changes nothing, but it effects all tools using
libapt like aptitude, synaptic or packagekit.
The exception remains apt-get for stretch for now as this might break
too many scripts/usecases too quickly.
The documentation is updated and extended to reflect how to opt out or
in on this behaviour change.
Closes: 808367
|
|
Most (if not all) solvers should be able to run perfectly fine without
root privileges as they get the entire state they are supposed to work
on via stdin and do not perform any action directly, but just pass
suggestions on via stdout.
The new default is to run them all as _apt hence, but each solver can
configure another user if it chooses/must. The security benefits are
minimal at best, but it helps preventing silly mistakes (see
35f3ed061f10a25a3fb28bc988fddbb976344c4d) and that is always good.
Note that our 'apt' and 'dump' solver already dropped privileges if they
had them.
|
|
|
|
For bugreports and co it could be handy to have the scenario and all the
settings used in it around later for inspection for EDSP like protocols.
EDSP might not be the most interesting as the user can still interrupt
the process before the solution is applied and users tend to have an
opinion on the "rightness" of a solution, so it is disabled by default.
|
|
In 8b79c94af7f7cf2e5e5342294bc6e5a908cacabf changing to usage of C++ way
of setting the locale causes us to be terminated in case of usage of an
ungenerated locale as LC_ALL (or similar) – but we don't want to fail
here, we just want to carry on as before with setlocale which we call in
that case just for good measure.
|
|
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
|
|
Broken in e7e10e47476606e3b2274cf66b1e8ea74b236757 by looking always
into "apt" while we ship some tools in "apt-utils"…
|
