| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This implements a apt update schema that get the indexfiles by the
hash instead of the name. The rational is that updates to the archive
servers/mirrors are not atomic so the client may have the previous
version of the Release file when the server updates to a new
Release file and new Packages/Sources/Translations indexes. By
keeping the files around by their hash we can still get the previous
indexfile without a hashsum mismatch.
Enable with APT::Acquire::By-Hash=1
|
|
debian/experimental
Conflicts:
apt-pkg/acquire-item.cc
apt-pkg/acquire-item.h
|
|
pkgAcq{DiffIndex,IndexMerge,pkgAcqBaseIndex, pkgAcqIndex}
|
|
If one of the pkgAcqIndex{,Merge}Diffs fails, they will run
pkgAcqIndex() which needs the IndexTarget/indexRecords data.
So we pass it along.
|
|
dpkg on Ubuntu 12.04 does not seem to support parsing arch-specific
dependencies, so we try to detect if we face such a dpkg in the test.
In the other test the order depends on libdb, which changes per arch, so
we just run it through our sorting binary and be happy (hopefully).
Git-Dch: Ignore
|
|
In bugreport #747261 I confirmed with this testcase that apt actually
supports the requested architecture-specific conflicts already since
2012 with commit cef094c2ec8214b2783a2ac3aa70cf835381eae1.
The old test only does simulations which are handy to check apt,
this one builds 'real' packages to see if dpkg agrees with us.
Git-Dch: Ignore
|
|
The cache heavily depends on the architecture(s) it is build for,
especially if you move from single- to multiarch. Adding a new
architecture to dpkg therefore has to be detected and must invalidate
the cache so that we don't operate on incorrect data.
The incorrect data will prevent us from doing otherwise sensible
actions (it doesn't allow bad things to happen) and the recovery is
simple and automatic in most cases, so this hides pretty well and is
also not as serious as it might sound at first.
Closes: 745036
|
|
Removes the 256 fields limit, deals consistently with spaces littered
all over the place and is even a tiny bit faster than before.
Even comes with a bunch of new tests to validate these claims.
|
|
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'.
|
|
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.
|
|
Beside being another big API break with hopefully zero fallout in
reality it avoids having the same member and helper code in each and
every subclass.
|
|
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.
LP: 1098738
|
|
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.
Git-Dch: Ignore
|
|
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.
Git-Dch: Ignore
|
|
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.
Git-Dch: Ignore
|
|
Git-Dch: Ignore
Reported-By: gcc
|
|
Git-Dch: Ignore
|
|
Git-Dch: Ignore
|
|
|
|
fetched, so why bother
|
|
size information"
This reverts commit 773642528b6d9858c2c68ada42705ea71c8db37e.
|
|
debian/experimental
Conflicts:
apt-pkg/deb/debindexfile.cc
apt-pkg/deb/debindexfile.h
apt-pkg/deb/debsrcrecords.cc
|
|
debian/experimental
|
|
|
|
bugfix/update-progress-reporting
|
|
|
|
debian/sid
|
|
|
|
debian/experimental
|
|
|
|
bugfix/update-progress-reporting
|
|
|
|
|
|
APT_PKG_MINOR < 13)
|
|
|
|
|
|
information
|
|
debian/experimental
|
|
debian/experimental
|
|
debian/sid
|
|
|
|
Conflicts:
apt-pkg/cachefilter.h
apt-pkg/contrib/fileutl.cc
apt-pkg/contrib/netrc.h
apt-pkg/deb/debsrcrecords.cc
apt-pkg/init.h
apt-pkg/pkgcache.cc
debian/apt.install.in
debian/changelog
|
|
about a good API
|
|
|
|
|
|
|
