The name suggests that it is supposed to substitute a variable with a
value, but we tend to use it in a more liberal replace_all() fashion,
but this breaks if either of the parameters is empty or more importantly
if two "variable" occurrences follow each other directly.
don't send pkg from an unknown architecture via EDSP
APT's cache can include packages from architectures dpkg has no
knowledge about and can therefore not be installed for e.g. to allow
easy lookups. There is no point in telling external solvers about them
though and some of them might even be really talkative about ignoring
them if we do.
In commit 21b3eac8 I promoted the check for installable dependencies to
a pre-install check, which also reverts to a known good candidate (the
installed version) if it fails. This revert was done even for user
requested candidate switches which disabled our Broken detection so that
install requests which are impossible to satisfy do not fail anymore,
but print an (incomplete) solution proposal and then exit successfully.
Michael Vogt [Fri, 30 May 2014 12:47:56 +0000 (14:47 +0200)]
Show unauthenticated warning for source packages as well
This will show the same unauthenticated warning for source packages
as for binary packages and will not download a source package if
it is unauthenticated. This can be overridden with
--allow-unauthenticated
EDSP code uses pipes opened via an FD as sources and later for those
files modification times and filesize are read - but never really used
again. The result we get from FileFd is probably wrong, but as we don't
use it anyway, we just don't fallback if we have nothing to fallback to
Solvers are supposed to exit successfully even if they haven't found a
solution, but a solver which fails drastically (like e.g. segfaults)
should be detected and dealt with accordingly instead of ignored.
if Resolver fails, do not continue even if not broken
This can happen if the request is already a well-formed request all by
itself (e.g. the package has no dependencies), but the resolver found
a reason to not accept it as solution. Our edsp 'dump' solver e.g.
shouldn't be able to trigger install, which it does otherwise.
As outlined in #748355 apt segfaulted if it encountered a loop between a
package pre-depending on a package conflicting with the previous as it
ended up in an endless loop trying to unpack 'the other package'.
In this specific case as an essential package is involved a lot of force
needs to be applied, but can also be caused by 'normal' tight loops and
highlights a problem in how we handle breaks which we want to avoid.
The fix comes in multiple entangled changes:
1. All Smart* calls are guarded with loop detection. Some already had it,
some had parts of it, some did it incorrect, and some didn't even try.
2. temporary removes to avoid a loop (which is done if a loop is
detected) prevent the unpack of this looping package (we tried to unpack
it to avoid the conflict/breaks, but due to a loop we couldn't, so we
remove/deconfigure it instead which means we can't unpack it now)
3. handle conflicts and breaks very similar instead of duplicating most
of the code. The only remaining difference is, as it should:
deconfigure is enough for breaks, for conflicts we need the big hammer
consistently fail if Smart* packagemanager actions fail
These failure conditions come with an error message attached and the
conditions aren't workaroundable (otherwise this would have been done
instead of returning failure), so not erroring out here means that we
execute dpkg later on with a known not-working ordering adding insult
(our own error messages at the end) to injury (dpkg failure).
add an additional test for arch specific conflicts
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.
Michael Vogt [Thu, 15 May 2014 12:37:33 +0000 (14:37 +0200)]
Never parse Version/Architecture tags in a Translation-$lang file
Version/Architecture information in a Translation-$lang file is
not allowed, so don't try to parse it. This is a fix for a bugreport
where a Translation-en file contained the content of the regular
Packages file (probably due to local FS corruption). This lead to
strange error messages on file download.
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.
projects / apt.git / log
