summaryrefslogtreecommitdiff
path: root/apt-pkg/deb
Commit message (Collapse)AuthorAgeFilesLines
* ParseDepends: Support passing the desired architectureNiels Thykier2017-01-022-3/+36
| | | | | | | | | | | This is useful for e.g. Britney, where the Build-Depends would have to be parsed for multiple architectures. With this change, the call can choose the architecture without having to mess with the config. Signed-off-by: Niels Thykier <niels@thykier.net> Closes: #845969 (jak@d.o: made the code compile)
* fix minimum pkgs option for dpkg --recursive usageDavid Kalnischkies2016-12-311-1/+1
| | | | | | Interpreting a boolean as an int works just fine – it just hasn't the intended result – it isn't a serious problem through as the disabling of the usage of this dpkg calling style is just an "optimization"
* avoid producing invalid options if repo has no hostDavid Kalnischkies2016-12-311-2/+5
| | | | | | | | This can happen e.g. for file: repositories. There is no inherent problem with setting such values internally, but its bad style, forbidden in the manpage and could be annoying in the future. Gbp-Dch: Ignore
* gets file location via FindFile instead of manual mergeDavid Kalnischkies2016-12-311-5/+6
| | | | | | | Unlikely to have any practical effect, but its more consistent to use the right methods instead of performing it slightly incorrect by hand. Gbp-Dch: Ignore
* skip unconfigure for unconfigured to-be removed pkgsDavid Kalnischkies2016-11-241-0/+12
|
* do not configure unconfigured to be removed packagesDavid Kalnischkies2016-11-241-1/+2
| | | | | | | | | | | | | We try to configure all packages at the end which need to be configured, but that also applies to packages which weren't completely installed (e.g. maintainerscript failed) we end up removing in this interaction instead. APT doesn't perform this explicit configure in the end as it is using "dpkg --configure --pending", but it does confuse the progress report and potentially also hook scripts. Regression-Of: 9ffbac99e52c91182ed8ff8678a994626b194e69
* don't perform implicit crossgrades involving M-A:sameDavid Kalnischkies2016-11-241-3/+22
| | | | | | dpkg stumbles over these (#844300) and we haven't dropped 'easier' removes to be implicit and to be scheduled by dpkg by default so far so we shouldn't push the decision in such cases to dpkg either.
* improve arch-unqualified dpkg-progress parsingDavid Kalnischkies2016-11-242-62/+155
| | | | | | | | | | | Our old idea was to look for the first package which would be "touched" and take this as the package dpkg is talking about, but that is incorrect in complicated situations like a package upgraded to/from multiple M-A:same siblings installed. As we us the progress report to decide what is still needed we have to be reasonabily right about the package dpkg is talking about, so we jump to quite a few loops to get it.
* correct cross & disappear progress detectionDavid Kalnischkies2016-11-231-35/+58
| | | | | | | | | | | | Given that we use the progress information to skip over actions dpkg has already done like not purging a package which was already removed and had no config files or not acting on disappeared packages and such it is important that apt and dpkg agree on which states the package has to pass through. To ensure that we keep tabs on this in the future a warning is added at the end if apt hasn't seen all the action it was supposed to see. I can't wait for the first bugreporters to wonder about this…
* react to trig-pend only if we have nothing else to doDavid Kalnischkies2016-11-231-12/+12
| | | | | | | | | If a package is triggered dpkg frequently issues two messages about it causing us to make a note about it both times which messes up our planned dpkg actions view. Adding these actions if we have nothing else planned fixes this and should still be correct as those planned actions will deal with the triggering just fine and we avoid strange problems like a package triggered before its removed…
* Do not use MD5SumValue for Description_md5()Julian Andres Klode2016-11-222-12/+11
| | | | | | | | | | | Our profile says we spend about 5% of the time transforming the hex digits into the binary format used by HashsumValue, all for comparing them against the other strings. That makes no sense at all. According to callgrind, this reduces the overall instruction count from 5,3 billion to 5 billion in my example, which roughly matches the 5%.
* debListParser: Micro-optimize AvailableDescriptionLanguages()Julian Andres Klode2016-11-221-8/+7
| | | | | | | | | | | | | Generating a string for each version we see is somewhat inefficient. The problem here is that the Description tag names are longer than 15 byte, and thus require an allocation on the heap, which we should avoid. It seems reasonable that 20 characters works for all languages codes used for archive descriptions, but if not, there's a warning, so we'll catch that. This should improve performance by about 2%.
* Optimize VersionHash() to not need temporary copy of inputJulian Andres Klode2016-11-221-14/+6
| | | | | | | Stop copying stuff, and just parse the bytes one by-one to the newly created AddCRC16Byte. This improves the instruction count for an update run from 720,850,121 to 455,801,749 according to callgrind.
* Introduce tolower_ascii_unsafe() and use it for hashingJulian Andres Klode2016-11-221-1/+1
| | | | | | | This one has some obvious collisions for non-alphabetical characters, like some control characters also hashing to numbers, but we don't really have those, and these are hash functions which are not collision free to begin with.
* debListParser: Convert to use pkgTagSection::Key-based lookupJulian Andres Klode2016-11-222-42/+42
| | | | | | This basically gets rid of 40-50% of the hash table lookups, making things a bit faster that way, and the profiles look far cleaner.
* add hidden config to set packages as Essential/ImportantDavid Kalnischkies2016-11-112-4/+16
| | | | | | | | | | | | | | | | You can pretty much achieve the same with a local dummy package if you want to, but libapt has an inbuilt setting for essential: "apt" which can be overridden with this option as well – it could be helpful in quick tests and what not so adding this alternative shouldn't really hurt much. We aren't going to document them much through as care must be taken in regards to the binary caches as they aren't invalidated by config options alone, so the effects of old settings could still be in them, similar to the other already existing pkgCacheGen option(s). Closes: 767891 Thanks: Anthony Towns for initial patch
* add support for Build-Depends/Conflicts-ArchJohannes Schauer2016-11-091-3/+5
| | | | | | | | | | | | | | These new enum values might cause "interesting" behaviour in tools not expecting them – like an old apt would think a Build-Conflicts-Arch is some sort of Build-Depends – but that can't reasonably be avoided and effects only packages using B-D/C-A so if there is any breakage the tools can easily be adapted. The APT_PKG_RELEASE number is increased so that libapt users can detect the availability of these new enum fields via: #if APT_PKG_ABI > 500 || (APT_PKG_ABI == 500 && APT_PKG_RELEASE >= 1) Closes: #837395
* VersionHash: Do not skip too long dependency linesJulian Andres Klode2016-09-181-2/+2
| | | | | | | | | | | | | | | If the dependency line does not contain spaces in the repository but does in the dpkg status file (because dpkg normalized the dependency list), the dpkg line might be longer than the line in the repository. If it now happens to be longer than 1024 characters, it would be skipped, causing the hashes to be out of date. Note that we have to bump the minor cache version again as this changes the format slightly, and we might get mismatches with an older src cache otherwise. Fixes Debian/apt#23
* Fix segfault and out-of-bounds read in Binary fieldsJulian Andres Klode2016-08-311-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | If a Binary field contains one or more spaces before a comma, the code produced a segmentation fault, as it accidentally set a pointer to 0 instead of the value of the pointer. If the comma is at the beginning of the field, the code would create a binStartNext that points one element before the start of the string, which is undefined behavior. We also need to check that we do not exit the string during the replacement of spaces before commas: A string of the form " ," would normally exit the boundary of the Buffer: binStartNext = offset 1 ',' binEnd = offset 0 ' ' isspace_ascii(*binEnd) = true => --binEnd => binEnd = - 1 We get rid of the problem by only allowing spaces to be eliminated if they are not the first character of the buffer: binStartNext = offset 1 ',' binEnd = offset 0 ' ' binEnd > buffer = false, isspace_ascii(*binEnd) = true => exit loop => binEnd remains 0
* Merge branch 'portability/freebsd'Julian Andres Klode2016-08-273-4/+7
|\
| * Make directory paths configurableJulian Andres Klode2016-08-261-4/+4
| | | | | | | | | | | | | | This allows other vendors to use different paths, or to build your own APT in /opt for testing. Note that this uses + 1 in some places, as the paths we receive are absolute, but we need to strip of the initial /.
| * Add missing includes and external definitionsJulian Andres Klode2016-08-262-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | treat .ddeb files like .deb, especially for dpkgDavid Kalnischkies2016-08-251-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | do not restore selections for already purged packagesDavid Kalnischkies2016-08-241-6/+15
|/ | | | | | | | | | | | | | | | | | 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
* do dpkg --configure before --remove/--purge --pendingDavid Kalnischkies2016-08-231-3/+7
| | | | | | | | | | | | | | | | | | | 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
* Ignore SIGINT and SIGQUIT for Pre-Install hooksJulian Andres Klode2016-08-191-7/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* add --with-source option and Packages/Sources supportDavid Kalnischkies2016-08-171-1/+5
| | | | | | | | | | | | | We support "./foobar.deb" as a way to install a deb file directly. Recently .changes files were added. This highlights a problem as you can't add the changes file without also trying to install all of them. Now, it could also be handy to add entire Packages/Sources files to perhaps get a bunch of packages in without installing them all implicitly. This commit introduces --with-source which allows to add *.deb, *.changes, *.dsc, source-dirs, Packages & Sources files (the later can also be compressed) without also installing them.
* default to Dir=/ in dpkg/status file finding magicDavid Kalnischkies2016-08-171-12/+10
| | | | | | | | | | | | | Seen in cme #833656 if Dir isn't set (yet) we end up later absoluting a path which was supposed to be absolute already, so if Dir is empty we assume it to be '/' instead. In practice this is a bug in the software using libapt, but for maxium compatibility lets explicitly set the default value here to be safe. Reported-By: Paul Wise <pabs@debian.org> Inspired-By: Brendan O'Dea <bod@debian.org> Fixes-Regression: 475f75506db48a7fa90711fce4ed129f6a14cc9a Shadows-Bug: #833656
* disable explicit configuration of all packages at the endDavid Kalnischkies2016-08-101-9/+3
| | | | | | | | | | | | | | | | | | | 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.
* simulate all package manager actions explicitlyDavid Kalnischkies2016-08-102-26/+32
| | | | | | | | | | | | | | | | | 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.
* try to avoid removal of crossgraded packagesDavid Kalnischkies2016-08-101-26/+140
| | | | | | | | 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.
* ensure all removes are reported to hook scriptsDavid Kalnischkies2016-08-101-0/+13
| | | | Same reason and implementation as for configure.
* ensure all configures are reported to hook scriptsDavid Kalnischkies2016-08-101-0/+17
| | | | | | | 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.
* don't purge directly, but remove and do purge at the endDavid Kalnischkies2016-08-101-61/+86
| | | | | | | | | | 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.
* call dpkg with --no-triggers by defaultDavid Kalnischkies2016-08-101-6/+7
| | | | | | | | | | | | | 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
* select remove/purge packages early on for dpkgDavid Kalnischkies2016-08-102-14/+84
| | | | | | | 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.
* save and restore selection states before/after calling dpkgDavid Kalnischkies2016-08-101-6/+36
| | | | | | | | | | | | 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.
* use dpkg --unpack --recursive to avoid long cmdlinesDavid Kalnischkies2016-08-101-7/+95
| | | | | | | | | | 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.
* pass --force-remove-essential to dpkg only if neededDavid Kalnischkies2016-08-101-2/+13
| | | | | | 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.
* Merge branch 'cmake'Julian Andres Klode2016-08-101-1/+1
|\
| * CMake: Check for ptsname_r() againJulian Andres Klode2016-08-101-1/+1
| | | | | | | | | | | | | | | | 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
* | Handle interrupt when running Pre-Install hooksJulian Andres Klode2016-08-071-0/+8
|/ | | | | | | | 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
* report progress for triggered actionsDavid Kalnischkies2016-07-221-15/+42
| | | | | | | | | | | | | 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.
* use a configurable location for apport report storageDavid Kalnischkies2016-07-221-1/+2
| | | | | Hardcoding /var/crash means we can't test it properly and it isn't really our style.
* report progress for removing while purging pkgsDavid Kalnischkies2016-07-221-20/+31
| | | | | | | | 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.
* support "install ./foo.changes"David Kalnischkies2016-07-222-2/+19
| | | | | | | | | | | | We support installing ./foo.deb (and ./foo.dsc for source) for a while now, but it can be a bit clunky to work with those directly if you e.g. build packages locally in a 'central' build-area. The changes files also include hashsums and can be signed, so this can also be considered an enhancement in terms of security as a user "just" has to verify the signature on the changes file then rather than checking all deb files individually in these manual installation procedures.
* allow arch=all to override No-Support-for-Architecture-allDavid Kalnischkies2016-07-221-11/+29
| | | | | | | | | | | | | If a user explicitly requests the download of arch:all apt shouldn't get in the way and perform its detection dance if arch:all packages are (also) in arch:any files or not. This e.g. allows setting arch=all on a source with such a field (or one which doesn't support all at all, but has the arch:all files like Debian itself ATM) to get only the arch:all packages from there instead of behaving like a no-op. Reported-By: Helmut Grohne on IRC
* refactor plus/minus sources.list option handlingDavid Kalnischkies2016-07-191-85/+108
| | | | | | | Moving code around into some more dedicated methods, no effective code change itself. Gbp-Dch: Ignore
* don't hardcode /var/lib/dpkg/status as dir::state::statusDavid Kalnischkies2016-07-191-3/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | Theoretically it should be enough to change the Dir setting and have apt pick the dpkg/status file from that. Also, it should be consistently effected by RootDir. Both wasn't really the case through, so a user had to explicitly set it too (or ignore it and have or not have expected sideeffects caused by it). This commit tries to guess better the location of the dpkg/status file by setting dir::state::status to a naive "../dpkg/status", just that this setting would be interpreted as relative to the CWD and not relative to the dir::state directory. Also, the status file isn't really relative to the state files apt has in /var/lib/apt/ as evident if we consider that apt/ could be a symlink to someplace else and "../dpkg" not effected by it, so what we do here is an explicit replace on apt/ – similar to how we create directories if it ends in apt/ – with dpkg/. As this is a change it has the potential to cause regressions in so far as the dpkg/status file of the "host" system is no longer used if you set a "chroot" system via the Dir setting – but that tends to be intended and causes people to painfully figure out that they had to set this explicitly before, so that it now works more in terms of how the other Dir settings work (aka "as expected"). If using the host status file is really intended it is in fact easier to set this explicitely compared to setting the new "magic" location explicitely.
* reinstalling local deb file is no downgradeDavid Kalnischkies2016-07-011-1/+1
| | | | | | | | | | | | If we have a (e.g. locally built) deb file installed and do try to install it again apt complained about this being a downgrade, but it wasn't as it is the very same version… it was just confused into not merging the versions together which looks like a downgrade then. The same size assumption is usually good, but given that volatile files are parsed last (even after the status file) the base assumption no longer holds, but is easy to adept without actually changing anything in practice.
generated by cgit v1.2.3-70-g09d2 (git 2.46.0) at 2024-11-05 16:33:59 +0000