summaryrefslogtreecommitdiff
path: root/apt-pkg/deb/dpkgpm.cc
AgeCommit message (Collapse)Author
2016-08-19Ignore SIGINT and SIGQUIT for Pre-Install hooksJulian Andres Klode
Instead of erroring out when receiving a SIGINT, let the child deal with it - we'll error out anyway if the child exits with an error or due to the signal. Also ignore SIGQUIT, as system() ignores it. This basically fixes Bug #832593, but: we are running the hooks via sh -c. Some shells exit with a signal error even if the command they are executing catches the signal and exits successfully. So far, this has been noticed on dash, which unfortunately, is our default shell. Example: $ cat trap.sh trap 'echo int' INT; sleep 10; exit 0 $ if dash -c ./trap.sh; then echo OK: $?; else echo FAIL: $?; fi ^Cint FAIL: 130 $ if mksh -c ./trap.sh; then echo OK: $?; else echo FAIL: $?; fi ^Cint OK: 0 $ if bash -c ./trap.sh; then echo OK: $?; else echo FAIL: $?; fi ^Cint OK: 0
2016-08-10disable explicit configuration of all packages at the endDavid Kalnischkies
With b4450f1dd6bca537e60406b2383ab154a3e1485f we dropped what we calculated here later on and now that we don't need it in the meantime either we can just skip the busy work by default and expect dpkg to do the right thing dropping also our little "last explicit configures" removal trick introduced in b4450f1dd6bca537e60406b2383ab154a3e1485f. This enables the last of a bunch of previously experimental options, some of them existing still, but are very special and hence not really worth documenting anymore (especially as it would need to be rewritten now entirely) which is why the documentation is nearly completely dropped. The order of configuration stanzas in the simulation code changes slightly as it isn't concerning itself with finding the 'right' order, but any order is valid anyhow as long as the entire set happens in the same call.
2016-08-10simulate all package manager actions explicitlyDavid Kalnischkies
If a planner lets actions to be figured out by dpkg in pending calls these actions aren't mentioned in a simulation. While that might be a good thing for debugging, it would be a change in behavior and especially if a planner avoids explicit removals could be confusing for users. As such we perform the same 'trick' as in the dpkg implementation by performing explicitly what would be done by the pending calls. To save us some work and avoid desyncs we perform a layer violation by using deb/ code in the generic simulation – and further we perform ugly dynamic_cast to avoid breaking the ABI for nothing; aptitude is the only other user of the simulation class according to codesearch.d.n and for that our little trick works. It just isn't working if you happen to extend pkgSimulate or otherwise manage to call the protected Go methods directly – which isn't very realistic/practical.
2016-08-10try to avoid removal of crossgraded packagesDavid Kalnischkies
The user has to approve the removal of a crossgraded package as it might be needed to remove it (temporarily) in the process, but in most cases we can happily avoid it and let dpkg unpack over it skipping the remove. This has some effects on progress reporting and how deal with selections through which makes this a tiny bit complicated.
2016-08-10ensure all removes are reported to hook scriptsDavid Kalnischkies
Same reason and implementation as for configure.
2016-08-10ensure all configures are reported to hook scriptsDavid Kalnischkies
A planner might not explicitly configure all packages, but we need to know all packages which will be configured for progress reporting and to tell the hook scripts about them as they rely on this for their own functionality.
2016-08-10don't purge directly, but remove and do purge at the endDavid Kalnischkies
If we want a package to be purged from the system tell dpkg in the ordering (if it has to touch it explicitly) to remove it and cover the purging of the config files at the end with a --purge --pending call. That should help packages move conffiles around between packages correctly even if the user is purging packages directly in big actions like dist-upgrades involving many packages.
2016-08-10call dpkg with --no-triggers by defaultDavid Kalnischkies
Implemented a long while ago now with relatively good progress reporting involving triggers is a good time to try delaying the execution of triggers across dpkg invocations finally by default. Note: The bugreport talks also about 'smarter' configuration which is a much bigger part and approached from multiple directions, but doesn't really involve triggers per-se so considering it decoupled should help in getting it done… Closes: #626599
2016-08-10select remove/purge packages early on for dpkgDavid Kalnischkies
Telling dpkg early on that we are going to remove these packages later helps it with auto-deconfiguration decisions and its another area where a planner can ignore the nitty gritty details and let dpkg decide the course of action if there are no special requirements.
2016-08-10save and restore selection states before/after calling dpkgDavid Kalnischkies
dpkg decides certain things on its own based on selections and especially if we want to call --pending on purge/remove actions, we need to ensure a clean slate or otherwise we surprise the user by removing packages we weren't allowed to remove by the user in this run (the selection might be an overarching plan for the not-yet "future"). Ideally dpkg would have some kind of temporal selection interface for this case, but it hasn't, so we make it temporal with the risk of loosing state if we don't manage to restore them.
2016-08-10use dpkg --unpack --recursive to avoid long cmdlinesDavid Kalnischkies
Having long commandlines split into two is a huge problem if it happens and additionally if we want to introduce planners which perform less micromanagment its a good idea to leave the details for dpkg to decide. In practice this doesn't work yet unconditionally as a bug is hiding in the ordering code of dpkg, but it works if apt imposes its ordering so this commit allows for now at least to solve the first problem.
2016-08-10pass --force-remove-essential to dpkg only if neededDavid Kalnischkies
APT (usually) knows which package is essential or not, so we can avoid passing this force flag to dpkg unconditionally if the user hasn't chosen a non-default essential handling obscuring the information.
2016-08-10Merge branch 'cmake'Julian Andres Klode
2016-08-10CMake: Check for ptsname_r() againJulian Andres Klode
This was dropped in autotools as I found no use of the HAVE_PTSNAME_R macro. Turns out it was typoed as HAVE_PTS_NAME_R. Fix the #ifdef and add checks to CMake for it. Closes: #833674
2016-08-07Handle interrupt when running Pre-Install hooksJulian Andres Klode
If we receive an interrupt, set a flag and do not abort immediately without waiting for the child. Once the child exited, exit with an error if the interrupted flag is set. Closes: #832593
2016-07-22report progress for triggered actionsDavid Kalnischkies
APT doesn't know which packages will be triggered in the course of actions, so it can't plan to see them for progress beforehand, but if it sees that dpkg says that a package was triggered we can add additional states. This is pretty much magic – after all it sets back the progress – and there are cornercases in which this will result in incorrect totals (package in partial states may or may not loose trigger states), but the worst which can happen is that the progress is slightly incorrect and doesn't reach 100%, but so be it. Better than being stuck at 100% for a while as apt isn't realizing that a bunch of triggers still need to be processed.
2016-07-22use a configurable location for apport report storageDavid Kalnischkies
Hardcoding /var/crash means we can't test it properly and it isn't really our style.
2016-07-22report progress for removing while purging pkgsDavid Kalnischkies
The progress reporting for a package sheduled for purging only included the states dpkg passes through while actually purging the package – if the package was fully installed before dpkg will pass first through all remove states before purging it, so in the interest of consistent reporting our progress reporting should do that, too.
2016-06-29write auto-bits before calling dpkg & again after if neededDavid Kalnischkies
Writing first means that even in the event of a power-failure the autobit is saved for future processing instead of "forgotten" so that the package is treated as manually installed. In some cases we have to re-run the writing after dpkg is done through as dpkg can let packages disappear and in such cases apt will move autobits around (or in that case non-autobits) which we need to store.
2016-06-29Revert "travis: use gcc-5 instead of gcc(-4.8)"David Kalnischkies
This reverts commit 2b8221d66a8284042fc53c7bbb14bb9750e9137f. Avoiding the use of GCC >= 5 stuff lets use go back to 4.8 simplifying the travis setup again as well as reducing the backport requirements in general. This is possible because the std::get_time use requiring GCC >= 5 in 9febc2b238e1e322dce1f94ecbed46d595893b52 was replaced by handrolling it in 1d742e01470bba27715a8191c50adde4b39c2f19, so the remaining uses are just small conviniences we can do without. Gbp-Dch: Ignore
2016-06-10don't leak dpkg statusfd pipe in debuggingDavid Kalnischkies
Not a big deal to leak fds in debugging mode, but for completeness. Git-Dch: Ignore
2016-06-09remove racy_pselect fallbackDavid Kalnischkies
The comment says it should have been removed with Lenny+1 which is a small while ago already, so it seems like a good time now… And as this is a cleanup commit it also gets right of spurious whitespace at the end of lines, adds missing fold markers and similar busy work. Git-Dch: Ignore
2016-06-08drop Dpkg::MaxArgs in favor of Dpkg::MaxArgsBytesDavid Kalnischkies
We had an old FIXME saying that it is probably pointless to do this if we limit by length of the commandline already and I completely agree. The splitting is bad enough if it must be done, so we should only do it if we have to (as in absolute length of commandline) and, but that is just a remark, it is unlikely that we ever have/had a call triggering this as the default value was ~32000 items…
2016-06-08don't explicitly configure the last round of packagesDavid Kalnischkies
We end our operation by calling "dpkg --configure -a", so instead of running a (big) configure run with all packages mentioned explicitly before this, we simply skip them and let them be handled by this call implicitly. There isn't really an observeable gain to be had here from a speed point, but it helps in avoiding an (uncommon) problem of having a too long commandline passed to dpkg, which we would split up (probably incorrectly).
2016-05-24fix two typos in untranslated errors of libapt-pkgDavid Kalnischkies
Reported-By: lintian: spelling-error-in-binary Git-Dch: Ignore
2016-05-03let DPKG_COLORS default to our APT::Color settingDavid Kalnischkies
dpkg can optionally colorize its output since 1.18.5. Currently this defaults to 'never', but it will eventually be 'auto'. It seems reasonable to assume that a user who has enabled/disabled colors in apt will want to have dpkg have the same state regarding color usage. This isn't overriding explicit settings by the user, so in case a user feels strongly about it one way or the other there are options.
2016-03-14streamline dpkgpm cleanup-handlingDavid Kalnischkies
The (unlikely) waitpid failure case should fallthrough the code just like the other failures (and successes) instead of taking a shortcut avoiding all the cleanup (progress) and finishing touches (log, state). This also delays the cleanup of the progress until apt is really done with everything and "just" has the post-invokes left to do, so the period of 'apt looks finished as it stopped the progress' and 'apt really finished as I have the shell-prompt back' is shorter even if there is no progress reported anymore, so the bar lingers at 100%… Ideally even the post-invokes would be covered by progress, but they can have their own output and dealing with that could be hard. Git-Dch: Ignore
2016-03-07Fix several typosVeres Lajos
This effectively merges branch 'typofixes-vlajos-20150807' of github.com:vlajos/apt with the following commit: commit 13cacb3e2e2352ba701e769fc889e3344fabbf7e Author: Veres Lajos <vlajos@gmail.com> Date: Sun Aug 9 00:12:53 2015 +0100 typofix - https://github.com/vlajos/misspell_fixer It has been rebased for a better commit message.
2016-02-26Add missing numeric includes in files using std::accumulate()Julian Andres Klode
Reported-By: Helmut Grohne on IRC
2016-01-25Use c++11 for loop in AptHistoryRequestingUserMichael Vogt
Git-Dch: ignore
2016-01-25Store "Requested-By" user in history.log in a simpler formatMichael Vogt
Git-Dch: ignore Thanks: David Kalnischkies
2016-01-25Log calling SUDO_USER or PKEXEC_UID in history.logMichael Vogt
Thanks: Thomas Reusch
2015-12-07Avoid overflow when summing up file sizesJulian Andres Klode
We need to pass 0llu instead of 0 as the init value, otherwise std::accumulate will calculate with ints. Reported-by: Raphaël Hertzog
2015-11-05apply various suggestions made by cppcheckDavid Kalnischkies
Reported-By: cppcheck Git-Dch: Ignore
2015-11-05do not use read() returned value unconditionallyDavid Kalnischkies
A slightly unlikely bug, but lets fix it while slightly reworking this whole function to be slightly saner to look at, even if still not good. Git-Dch: Ignore
2015-11-04wrap every unlink call to check for != /dev/nullDavid Kalnischkies
Unlinking /dev/null is bad, we shouldn't do that. Also, we should print at least a warning if we tried to unlink a file but didn't manage to pull it of (ignoring the case were the file is /dev/null or doesn't exist in the first place). This got triggered by a relatively unlikely to cause problem in pkgAcquire::Worker::PrepareFiles which would while temporary uncompressed files (which are set to keep compressed) figure out that to files are the same and prepare for sharing by deleting them. Bad move. That also shows why not printing a warning is a bad idea as this hide the error for in non-root test runs. Git-Dch: Ignore
2015-11-04sanify API to get 'the' candidate versionDavid Kalnischkies
This was discussed a while ago on #debian-apt and now that I see myself making this mistake lets bite the bullet and fix it in the easy way out version: Using a new name which fits with a similar named setter and deprecate the old method instead of 'hostily' changing API. Closes: #803471
2015-11-04implement a public pkgSystem::MultiArchSupportedDavid Kalnischkies
Some codepaths need to check if the system (in our case usually dpkg) supports MultiArch or not. We had copy-pasted the check so far into these paths, but having it as a system check is better for reusability.
2015-10-30dpkgpm: Convert users of localtime() to localtime_r()Julian Andres Klode
The former is not thread-safe, whereas the latter is. Gbp-Dch: ignore
2015-10-30dpkgpm: Use ptsname_r() instead of ptsname() to be thread-safeJulian Andres Klode
This function only exists on a limited number of platforms, so we add a configure check to make sure it exists. Gbp-Dch: ignore
2015-10-30dpkgpm: Convert ctime() call to ctime_r()Julian Andres Klode
ctime() is not thread-safe, ctime_r() is. Gbp-Dch: ignore
2015-09-14avoid using global PendingError to avoid failing too often too soonDavid Kalnischkies
Our error reporting is historically grown into some kind of mess. A while ago I implemented stacking for the global error which is used in this commit now to wrap calls to functions which do not report (all) errors via return, so that only failures in those calls cause a failure to propergate down the chain rather than failing if anything (potentially totally unrelated) has failed at some point in the past. This way we can avoid stopping the entire acquire process just because a single source produced an error for example. It also means that after the acquire process the cache is generated – even if the acquire process had failures – as we still have the old good data around we can and should generate a cache for (again). There are probably more instances of this hiding, but all these looked like the easiest to work with and fix with reasonable (aka net-positive) effects.
2015-08-17Cleanup includes after running iwyuMichael Vogt
2015-08-12Do not set unhonored DPKG_NO_TSTP variable for dpkgGuillem Jover
Support for that variable was removed in dpkg in 1.15.6, in commit 6f037003e8b96878b485efb7cbd1f846e3bf4e97. Closes: #765366
2015-08-10remove the compatibility markers for 4.13 abiDavid Kalnischkies
We aren't and we will not be really compatible again with the previous stable abi, so lets drop these markers (which never made it into a released version) for good as they have outlived their intend already. Git-Dch: Ignore
2015-08-10fix memory leaks reported by -fsanitizeDavid Kalnischkies
Various small leaks here and there. Nothing particularily big, but still good to fix. Found by the sanitizers while running our testcases. Reported-By: gcc -fsanitize Git-Dch: Ignore
2015-08-10make all d-pointer * const pointersDavid Kalnischkies
Doing this disables the implicit copy assignment operator (among others) which would cause hovac if used on the classes as it would just copy the pointer, not the data the d-pointer points to. For most of the classes we don't need a copy assignment operator anyway and in many classes it was broken before as many contain a pointer of some sort. Only for our Cacheset Container interfaces we define an explicit copy assignment operator which could later be implemented to copy the data from one d-pointer to the other if we need it. Git-Dch: Ignore
2015-06-12store Release files data in the CacheDavid Kalnischkies
We used to read the Release file for each Packages file and store the data in the PackageFile struct even through potentially many Packages (and Translation-*) files could use the same data. The point of the exercise isn't the duplicated data through. Having the Release files as first-class citizens in the Cache allows us to properly track their state as well as allows us to use the information also for files which aren't in the cache, but where we know to which Release file they belong (Sources are an example for this). This modifies the pkgCache structs, especially the PackagesFile struct which depending on how libapt users access the data in these structs can mean huge breakage or no visible change. As a single data point: aptitude seems to be fine with this. Even if there is breakage it is trivial to fix in a backportable way while avoiding breakage for everyone would be a huge pain for us. Note that not all PackageFile structs have a corresponding ReleaseFile. In particular the dpkg/status file as well as *.deb files have not. As these have only a Archive property need, the Component property takes over this duty and the ReleaseFile remains zero. This is also the reason why it isn't needed nor particularily recommended to change from PackagesFile to ReleaseFile blindly. Sticking with the earlier is usually the better option.
2015-04-19Merge branch 'debian/jessie' into debian/experimentalDavid Kalnischkies
Conflicts: apt-pkg/acquire-item.cc cmdline/apt-key.in methods/https.cc test/integration/test-apt-key test/integration/test-multiarch-foreign
2015-04-07fix crash in order writing in pkgDPkgPM::WriteApportReport()Michael Vogt
libapt can be configured to write various bits of information to a file creating a report via apport. This is disabled by default in Debian and apport residing only in /experimental so far, but Ubuntu and other derivatives have this (in some versions) enabled by default and there is no regression potentially here. The crash is caused by a mismatch of operations vs. strings for operations, so adding the missing strings for these operations solves the problem. [commit message by David Kalnischkies] LP: #1436626