If a (Pre-)Depends can't be satisfied there is no point in keeping the
candidate as is as it is impossible to find a solution for it, so we can
just as well reset the candidate to the currently installed version.
We avoid trying to install this impossible candidate later on this way.
The offset variable in DebSrcRecordParser was not initialized which we
now do and based on it do not trigger a restart if the parser was not
used yet avoiding a needless rescan of the section.
Detected while working on the previous commit e62aa1dd. Both commits act
as a "fix" for the bug shown in the testcase of the commit – this one
here would only hide it through.
pkgTagFile: if we have seen the end, do not try to see more
Asking for more via Step() will notice that we are done with the file
already and will result in a fail, which means we can't find the last
sections anymore (which is especially painful if we haven't moved at
all as in the testcase we haven't even looked at one of the sources
leading to a strange behaviour)
Michael Vogt [Fri, 24 Jan 2014 19:33:02 +0000 (20:33 +0100)]
add "apt full-upgrade" and tweak "apt upgrade"
There is a new "apt full-upgrade" that performs a apt-get dist-upgrade.
"apt dist-upgrade" is still supported as a alias. The "apt upgrade" code
is changed so that it mirrors the behavior of
"apt-get upgrade --with-new-pkgs" and also honors
"apt uprade --no-new-pkgs".
Michael Vogt [Sat, 18 Jan 2014 20:10:58 +0000 (21:10 +0100)]
* implement deb822 suggestions from donkult (thanks!):
- rename "Dist" to "Suites"
- rename "Section" to "Sections"
- rename "Architectures-Delete" to "Architectures-Remove"
- rename "Uri" to "URI"
* add "apt list --manual-installed"
* add "apt upgrade --dist"
* add "apt purge"
* flock() the file edited in "apt edit-sources"
* apt-private/private-show.cc:
- do not show Description-lang: header
* reword apt !isatty() warning
* add missing integration test for "apt list" and fix bugs
found by it
Without a PTY attached do not use color, but use the same MSGLEVEL with
or without a PTY. The level is better adjust via flags – especially as
it is likely that without a PTY you want fullblown logs instead of
the reduced display you get with -q otherwise.
otherwise you get with pickier umasks errors like:
dpkg-deb: error: control directory has bad permissions 700 (must be
>=0755 and <=0775)
so we just force a 755 for the control directory and dpkg is happy.
Maintaining (mainly the deletion of them) is a pain and they litter /tmp
while the testcase is run for no good reason as we could just as well
drop it into our tmpdir we have anyway and let them be deleted with the
rest automatically
improve stdout/stderr usage correctness in test framework
Also adds a friendly note about how many tests were run/passed so that
the end of the testrun isn't all that negative by just showing fails.
(It now tells us that we have 111 tests at the moment!)
integrate Anthonys rred with POC for client-side merge
Providing the benefits of both without the downsides :)
(ABI breaks or external dependencies)
For this Anthonys rred is equipped with:
- magic-filename-pickup of patches rather than explicit messages
- use of FileFd instead of FILE* to get on-the-fly uncompress
of the gzip compressed pdiff patches
The acquire code in turn stops checking for apt-file's helper
as our own rred is now clever enough for our needs.
Anthony Towns [Wed, 15 Jan 2014 15:33:36 +0000 (16:33 +0100)]
reimplement rred to allow applying all the diffs in a single pass
Based on the idea presented in:
https://lists.debian.org/deity/2009/08/msg00169.html and
https://lists.debian.org/debian-devel/2014/01/msg00081.html
It reads all patches one by one and merges them in-memory before
applying the merged changes to the index.
Beware: This commit by David Kalnischkies rips out the rred binary
rewrite unchanged (expect minor format issue corrections) from the
proposed changes, so this commit alone BREAKS pdiff completely.
The integration into the acquire system as it was prepared in the
previous POC will be done in the next commit to have proper 'blame'.
In 51fc6def77edfb1f429a48e5169519e9e05a759b we limited the amount of
pdiff to be downloaded per index to 20. This was a compromise between
not letting it go overboard (becoming even slower) and not using
bandwidth needlessly. Now that with the POC the speed reason is gone it
makes sense again to download as much files as we possible can via pdiff
to save bandwidth (and possibly even time).
It also avoids problems with the limit in cases we were we deal with a
server merged archieve as this limit assumes a strict patch progression.
projects / apt.git / log
