parse and retrieve multiple Descriptions in one record
It seems unlikely for now that proper archives will carry multiple
Description-* stanzas in the Packages (or Translation-*) file, but
sometimes apt eats its own output as shown by the usage of the CD team
and it would be interesting to let apt output multiple translations
e.g. in 'apt-cache show'.
reenable pipelining via hashsum reordering support
Now that methods have the expected hashes available they can check if
the response from the server is what they expected. Pipelining is one of
those areas in which servers can mess up by not supporting it properly,
which forced us to disable it for the time being. Now, we check if
we got a response out of order, which we can not only use to disable
pipelining automatically for the next requests, but we can fix it up
just like the server responded in proper order for the current requests.
To ensure that this little trick works pipelining is only attempt if we
have hashsums for all the files in the chain which in theory reduces the
use of pipelining usage even on the many servers which work properly,
but in practice only the InRelease file (or similar such) will be
requested without a hashsum – and as it is the only file requested in
that stage it can't be pipelined even if we wanted to.
Some minor annoyances remain: The display of the progress we have
doesn't reflect this change, so it looks like the same package gets
downloaded multiple times while others aren't at all. Further more,
partial files are not supported in this recovery as the received data
was appended to the wrong file, so the hashsum doesn't match.
Both seem to be minor enough to reenable pipelining by default until
further notice through to test if it really solves the problem.
This therefore reverts commit 8221431757c775ee875a061b184b5f6f2330f928.
Now that we have all hashes in the acquire system, pass the info down to
the methods, so that it can use it in the request and/or to precheck the
response.
deal with hashes in ftparchive more dynamic as well
Now that libapts acquire system happily passes around hashes and can be
made to support new ones without an ABI break in the future, we can
free ftparchive from all the deprecation warnings the last commit
introduced for it.
The goal here isn't to preserve ABI as we have none to keep here, but to
help avoiding introduction problems of 'new' hashes later as bugs creep
into the copy&paste parts, so short/less of them is good.
It is not very extensible to have the supported Hashes hardcoded
everywhere and especially if it is part of virtual method names.
It is also possible that a method does not support the 'best' hash
(yet), so we might end up not being able to verify a file even though we
have a common subset of supported hashes. And those are just two of the
cases in which it is handy to have a more dynamic selection.
The downside is that this is a MAJOR API break, but the HashStringList
has a string constructor for compatibility, so with a bit of luck the
few frontends playing with the acquire system directly are okay.
Collect all hashes we can get from the source record and put them into a
HashStringList so that 'apt-get source' can use it instead of using
always the MD5sum.
We therefore also deprecate the MD5 struct member in favor of the list.
While at it, the parsing of the Files is enhanced so that records which
miss "Files" (aka MD5 checksums) are still searched for other checksums
as they include just as much data, just not with a nice and catchy name.
APT supports more than just one HashString and even allows to enforce
the usage of a specific hash. This class is intended to help with
storage and passing around of the HashStrings.
tests: be able to disable "Fetched …" statistics message
The line contains everchanging execution statistics which is harmful for
testcases as they need to filter out such lines, but this is hard so we
can just add an option to disable them instead and be done.
Arrays with predefined lengths are very fragile as they are
likely forgotten in future changes and the size in this case
is dynamic making it even more dangerous.
initialize Verify in second pkgAcqIndex constructor
gcc reports in testcase ./test-bug-596498-trusted-unsigned-repo:
apt-pkg/acquire-item.cc:1059:7: runtime error: load of value 234, which
is not a valid value for type 'bool'
This happens as the bool Verify is initialized only in one of the two
constructors of the pkgAcqIndex class. It isn't a problem through as the
verification controlled by this flag is optional and used to fail early
on garbage files (like network portal pages) instead of later on in the
hashsum verification or while parsing (the then untrusted) file.
Adam Conrad [Sat, 26 Apr 2014 08:24:40 +0000 (10:24 +0200)]
fix FileFd::Size bitswap on big-endian architectures
gzip only gives us 32bit of size, storing it in a 64bit container and
doing a 32bit flip on it has therefore unintended results.
So we just go with a exact size container and let the flipping be handled
by eglibc provided le32toh removing our #ifdef machinery.
Debian wheezy shipped MultiArch to the masses and the predictions
remained true in sofar as little changes in apt itself and many
other frontends were needed compared to the fallout if done differently.
The info included is this file is therefore no longer current and adds
no useful information anymore, so we can drop it for good.
Modified by commiter to not publicily export the codename (as the
manpages do not use it that way) and removing the included additional
derives logic as it was not working (the link always exists at that
point) and isn't needed as we do the special casing for debian mainly
because it would shallow all distributions otherwise.
(similar, but not that strong for ubuntu)
The bugreport highlights the problem with an empty package name. We fix
this by 'ignoring' these so that it behaves just like "apt-get install".
The deeper problem is that modifier strings can be longer than a package
name in which case the comparison doesn't make sense, so don't compare
then. Was not noticed so far as all modifiers are of length 1, so the
only package name shorter than this is in fact the empty package name.
John Ogness [Mon, 21 Apr 2014 09:54:34 +0000 (11:54 +0200)]
properly undo CD-ROM mount in all error cases
In bug #740673 various issues in the CD-ROM handling code were
identified, while most the issues ended up being fixed in another way,
the unmounting of the CD-ROM in error cases was not tackled so far.
dist-upgrade is supposed to be an alias for full-upgrade in apt, but
dist-upgrade was the only command recognized of the two in the option
and flags recognition code.
extract travis installs from build-depends automatically
I forgot to add libgtest-dev to the list of packages to install on
travis, so this slightly hacky oneliner might prevent us from having
the same problem again if we happen to change dependencies again.
My commit 45df0ad2 from 26. Nov 2009 had a little remark:
"The commit also includes a very very simple testapp."
This was never intended to be permanent, but as usually…
The commit adds the needed make magic to compile gtest statically
as it is required and links it against a small runner. All previous
testcase binaries are reimplemented in gtest and combined in this
runner. While most code is a 1:1 translation some had to be rewritten
like compareversion_test.cc, but the coverage remains the same.
fseek and co do this to their eof-flags and it is more logic this way as
we will usually seek away from the end (e.g. to re-read the file).
The commit also improves the testcase further and adds a test for the
binary compressor codepath (as gz, bzip2 and xz are handled by
libraries) via the use of 'rev' as a 'compressor'.
force fancy progressbar redraw on window size change
We always reacted on the size change, but the bar is only redraw if the
precentage changes, which can take quiet a while in big upgrades, so
with a bit of refactoring we can now call for a redraw immediate to fix
this.
This refactor also helps in avoiding obscure pitfalls clangs static
analyser was complaining about (namely failure of ioctl resulting in
garbage values in the struct).
Instructing gcc (or clang) to prepare for capturing coverage data is
easy: Just build with: CXXFLAGS=--coverage
The hard part is that our buildsystem uses relative paths and so
confuses the hell out of lcov as it assumes this way that all our *.cc
files are in the same directory… by changing to absolute paths in the
compile rules we solve this problem.
Still not perfect as it refers to build/include files for most headers
and our forking/threading code isn't properly captured, but good enough
to see red reports for now:
CXXFLAGS=--coverage make
make test
./test/integration/run-tests -q
lcov --no-external --directory . --capture --output-file apt.info
genhtml --output-directory ./coverage/ apt.info
consider priorities only for downloadable pkgs in resolver
A package which can't be downloaded anymore is very likely dropped from
a release and can therefore no longer be 'standard' (or similar). We
therefore do not grant points for them anymore and demote them to
prio:extra instead which helps other packages breaking them away even if
they have a lower priority.
The testcase was initially created by Michael Vogt and just amended.
We now do Open, Write and Read (the later multiple ways) for each
permission and each compressor we have configured to cover more cases
and especially ensure that compressors do not change our premissions.
This test is also to be credited for discovering the skippos-fix.
deal with umask only if we really need to for mkstemp
As the comment actually says: open() does the umask dance by itself, so
we don't need to do it for it. We have to do it after mkstemp in Atomic
though, so move it into the if.
Also removes the "micro-optimisation" "FilePermissions == 600" as it
doesn't trigger at the moment anyway as 600 != 0600.
projects / apt.git / log
