detect zlib correctly. We still don't allow to build without it to remain
compatible with users accessing it directly, but this prepares for a drop
of this strict requirement in the future
* cmdline/apt-get.cc:
- distinguish information about 'apt-get autoremove' based on the
number of auto-removed packages both before and after the list
of packages (Closes: #665833)
* doc/*:
- move the command synopsis out of each manpage into apt-verbatim.ent
as they are a hell to translate and just single out the parameters
which can be translated to apt.ent
* apt-inst/database.{cc,h}, apt-inst/deb/dpkgdb.{cc,h}:
- drop instead of fix as it is only needed if you want to reimplement dpkg
and comes straight from the beginning of last decade (Closes: #663372)
* apt-inst/deb/debfile.cc:
- {Extract,Merge}Control() is another instance of "lets reimplement dpkg"
so shot of this code before someone ends up using this…
do not update po and pot files in the process of the build as this
causes timestamp changes for the mo files which therefore can't
be refcounted by dpkg for your M-A: same packages
(Closes: #659333, LP: #924628)
The commit also enables a top-level 'make update-po' and does
all the needed changes to let this work now that update-po might
be called in a freshly checkout tree
* methods/rred.cc:
- check return of writev() as gcc recommends
* methods/mirror.cc:
- check return of chdir() as gcc recommends
* apt-pkg/deb/dpkgpm.cc:
- check return of write() a gcc recommends
* apt-inst/deb/debfile.cc:
- check return of chdir() as gcc recommends
* apt-inst/deb/dpkgdb.cc:
- check return of chdir() as gcc recommends
* apt-pkg/acquire-worker.cc:
- check return of write() as gcc recommends
* apt-pkg/acquire.cc:
- check return of write() as gcc recommends
* apt-pkg/cdrom.cc:
- check return of chdir() and link() as gcc recommends
* apt-pkg/clean.cc:
- check return of chdir() as gcc recommends
* apt-pkg/contrib/netrc.cc:
- check return of asprintf() as gcc recommends
* apt-pkg/packagemanager.cc:
- recheck all dependencies if we changed a package in SmartConfigure
as this could break an earlier dependency (LP: #940396)
* apt-pkg/packagemanager.cc:
- fix bug in predepends handling - ensure that packages that needs
unpackaging are unpacked before they are configured (LP: #927993)
[ Julian Andres Klode ]
* apt-pkg/deb/deblistparser.cc:
- Set the Essential flag on APT instead of only Important
* apt-pkg/packagemanager.cc:
- Do not use immediate configuration for packages with the Important flag
* Treat the Important flag like the Essential flag with those differences:
- No Immediate configuration (see above)
- Not automatically installed during dist-upgrade
- No higher score for installation ordering
Michael Vogt [Tue, 6 Mar 2012 16:22:44 +0000 (17:22 +0100)]
* apt-pkg/acquire-item.cc:
- remove 'old' InRelease file if we can't get a new one before
proceeding with Release.gpg to avoid the false impression of a still
trusted repository by a (still present) old InRelease file.
Thanks to Simon Ruderich for reporting this issue! (CVE-2012-0214)
Michael Vogt [Tue, 6 Mar 2012 13:06:38 +0000 (14:06 +0100)]
* apt-pkg/packagemanager.cc:
- fix bug in predepends handling - ensure that packages that needs
unpackaging are unpacked before they are configured (LP: #927993)
* Treat the Important flag like the Essential flag with two differences:
- No Immediate configuration (see above)
- Not automatically installed during dist-upgrade
as we parse datestrings from external sources a lot specify the length
of the integer fields as well to avoid crashes in scanf as cppchecks warns:
"(warning) scanf without field width limits can crash with huge input data"
fix "(style) Statements following return, break, continue, goto or throw
will never be executed." from cppcheck. The fd was closed only after a
return, so invert the order of lines and be happy
* apt-pkg/acquire-item.cc:
- remove 'old' InRelease file if we can't get a new one before
proceeding with Release.gpg to avoid the false impression of a still
trusted repository by a (still present) old InRelease file.
Thanks to Simon Ruderich for reporting this issue! (CVE-2012-0214)
Effected are all versions >= 0.8.11
Possible attack summary:
- Attacker needs to find a user which has run at least one successful
'apt-get update' against an archive providing InRelease files.
- Create a Packages file with his preferred content.
- Attacker then prevents the download of InRelease, Release and
Release.gpg (alternatively he creates a valid Release file and sends
this, the other two files need to be missing either way).
- User updates against this, getting the modified Packages file without
any indication of being unsigned (beside the "Ign InRelease" and
"Ign Release.gpg" in the output of 'apt-get update').
=> deb files from this source are considered 'trusted' (and therefore the
user isn't asked for an additional confirmation before install)
Michael Vogt [Fri, 2 Mar 2012 21:01:51 +0000 (22:01 +0100)]
* apt-pkg/packagemanager.cc:
- when calculating pre-dependencies ensure that both unpack and
configure are considered (instead of only configure) LP: #927993
* cmdline/apt-get.cc:
- if a package can't be removed as it is not installed, suggest to
the user an (installed) multiarch silbing with 'Did you mean?'
* apt-pkg/acquire-item.cc:
- drop support for i18n/Index file (introduced in 0.8.11) and use
the Release file instead to get the Translations (Closes: #649314)
* ftparchive/writer.cc:
- add 'Translation-*' to the default patterns
i18n/Index was never used outside debian - and even here it isn't used
consistently as only 'main' has such a file. As the Release file now
includes the Translation-* files we therefore drop support for i18n/Index.
A version supporting it was never part of a debian release and still
supporting it would mean that we get 99% of the time a 404 as response
to the request anyway and confuse archive maintainers who want to
provide all files APT tries to acquire.
Fix the testcases to work with and configure dpkg correctly in a
multi-arch environment
It's not a complete and the "fixed" test is fixed more like a hack
as we have communication problems with dpkg if dpkg and APT disagree
on the interpretation of the native architecture, see also:
http://lists.debian.org/debian-dpkg/2012/02/msg00051.html