Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.3 2016-08-26T22:31:03Z 2016-08-26T22:31:03Z Julian Andres Klode jak@debian.org 2016-08-26T22:31:03Z urn:sha1:6a68315e938eb2611806658828ecea86805822e7 2016-08-26T13:49:10Z Julian Andres Klode jak@debian.org 2016-08-23T11:15:15Z urn:sha1:24a59c62efafbdb8387b2d3c5616b04b9fd21306 Several modules use std::array without including the array header. Bad modules. Some modules use STDOUT_FILENO and friends, or close() without including unistd.h, where they are defined. One module also uses WIFEXITED() without including sys/wait.h. Finally, environ is not specified to be defined in unistd.h. We are required to define it ourselves according to POSIX, so let's do that. 2016-08-25T14:12:24Z David Kalnischkies david@kalnischkies.de 2016-08-25T13:52:30Z urn:sha1:4f242a2289cc5db7a53afdb875291c94de64fd90 Ubuntu uses *.ddeb files for their debug packages, but the interface we are using since f495992428a396e0f98886c9a761a804aa161c68 to talk to dpkg isn't supporting *.ddeb files. This used to work previously as apt itself isn't caring about the filenames at all and if they are explicitly mentioned dpkg will accept all, too. It might or might not be a good idea to patch dpkg, too, but regardless of it happening, we don't want to couple us to closely to dpkg for this minor feature but testing for this at runtime as it would delay shipping the fix for the too long commandlines further. It is also questionable if it is really a good idea to allow any file extension to be used here (like .foobar in the testcase), but we used to and we tend to avoid breaking existing usecases if we can help it. As a bonus, this also allows the installation of ddeb files directly from the commandline as you can with deb files already. We continue to ignore udeb through as the user-mistake to useful ratio is too high. LP: #1616909 2016-08-24T20:37:41Z David Kalnischkies david@kalnischkies.de 2016-08-24T19:57:53Z urn:sha1:70ff288b98a7aae2c2808112015d34f76f2d5114 In most cases apt was already skipping the (re)setting of packages as to be removed/purged if dpkg had told us that it already did, but we haven't dealt with it in the most obvious of the cases: Selections set for packages we touched in this operation which either restores selections even dpkg would have overridden or e.g. tries to restore a purge selection for a package which was just purged – does not happen with apt itself as it isn't using selections in this way, but higher frontends like aptitude do. The result in the later case is a warning printed by dpkg that we try to set selections for an unknown package, which is harmless per se, but can be confusing for users and we really shouldn't cause warnings in dpkg if we can help it. Reported-By: Guillem Jover on IRC 2016-08-23T09:32:23Z David Kalnischkies david@kalnischkies.de 2016-08-22T19:33:38Z urn:sha1:fb51ce3295929947555f4883054f210a53d9fbdf Commit 7ec343309b7bc6001b465c870609b3c570026149 got us most of the way, but the last mile was botched by having the pending calls in the wrong order as this way we potentially 'force' dpkg to remove/purge a package it doesn't want to as another package still depends on it and the replacement isn't fully installed yet. So what we do now is a configure before remove and purge (all with --no-triggers) and finishing off with another configure pending call to take care of the triggers. Note that in the bugreport example our current planner is forcing dpkg to remove the package earlier via --force-depends which we could do for the pending calls as well and could be used as a workaround, but we want to do less forcing eventually. Closes: 835094 2016-08-19T14:45:03Z Julian Andres Klode jak@debian.org 2016-08-19T11:00:33Z urn:sha1:a6ae3d3df490e7a5a1c8324ba9dc2e63972b1529 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-10T21:51:35Z David Kalnischkies david@kalnischkies.de 2016-07-28T07:13:24Z urn:sha1:28557f94578602f9ce0011501a2259bd98ab0688 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-10T21:51:34Z David Kalnischkies david@kalnischkies.de 2016-07-28T09:43:36Z urn:sha1:4326680d2ed23d597f45ca8872a7054368560acc 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-10T21:51:34Z David Kalnischkies david@kalnischkies.de 2016-07-25T14:36:53Z urn:sha1:83e5cffc2015aa809acac84737756d292d7bf106 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-10T21:18:04Z David Kalnischkies david@kalnischkies.de 2016-07-24T17:00:08Z urn:sha1:bfc0933abedcd57e0a5bd07e282f3a50ba1fa5b2 Same reason and implementation as for configure.