summaryrefslogtreecommitdiff
path: root/apt-private/private-source.cc
AgeCommit message (Collapse)Author
2017-07-12Drop cacheiterators.h includeJulian Andres Klode
Including cacheiterators.h before pkgcache.h fails because pkgcache.h depends on cacheiterators.h.
2017-01-19fix various typos reported by spellintianDavid Kalnischkies
Most of them in (old) code comments. The two instances of user visible string changes the po files of the manpages are fixed up as well. Gbp-Dch: Ignore Reported-By: spellintian
2016-12-31allow default build-essentials to be overriddenDavid Kalnischkies
The config list APT::Build-Essential gets a similar treatment to other lists now by having the value of the option itself be an override for the list allowing to disable build-essentials entirely as well as adding/overriding as usual by now in other lists. Reported-By: Johannes 'josch' Schauer on IRC
2016-12-31add --indep-only for build-dep commandDavid Kalnischkies
The implementation is quite different compared to --arch-only due to ABI reasons but functionality wise they are similar and usually both available for symmetry at least. Closes: #845775
2016-12-16default to --no-check for dpkg-source callDavid Kalnischkies
In bug #757534 the opposite direction was initially requested, but what we did end up with was having a possibility to configure the options passed to dpkg. The reasoning given their and in #724744 is specific why apt doesn't need the checks to be performed by dpkg. In fact, what these two reports show is that if those checks are run people end up being confused about the requirement of them being run, so given the best case those checks can do is do nothing (visibly) while the worst cases are warnings and errors which are neither we are from a security point better of with disabling them – as (as mentioned in the bugreports) false positives for issues are really really bad in a security context. Closes: 724744
2016-12-16remove needless fork() in apt-get sourceDavid Kalnischkies
We are calling system() in this code paths, so all we do here is having a single child performing the action while the parent waits for it to finish… with the added strangeness of not having our usual error message collection and giving up after first failure even if told to act on multiple packages.
2016-12-16let {dsc,tar,diff}-only implicitly enable download-onlyDavid Kalnischkies
That was the case already for tar-only and diff-only, but in a more confusing way and without a message while dsc "worked" before resulting in a dpkg-source error shortly after as tar/diff files aren't available…
2016-11-09add support for Build-Depends/Conflicts-ArchJohannes Schauer
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
2016-07-22support "install ./foo.changes"David Kalnischkies
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.
2016-06-22source: if download is skipped, don't try to unpackDavid Kalnischkies
If apt decides it can't download a file it is relatively pointless to try to tell dpkg-source to unpack it.
2016-05-27prevent C++ locale number formatting in text APIsDavid Kalnischkies
Setting the C++ locale via std::locale::global(std::locale("")); which would otherwise default to the default C locale (aka: unaffected by setlocale) effects the formatting of numeric types in IO streams, which for output for humans is perfectly sensible, but breaks our many text interfaces used and parsed by us and others without expecting the numbers to be formatted. Closes: #825396
2016-03-06support APT::Get::Build-Dep-Automatic again in build-depDavid Kalnischkies
In a249b3e6fd798935a02b769149c9791a6fa6ef16 I dropped with the manual first resolver step also the support for installing build-deps as automatic in such a way that it behaved like this option was enabled by default. Restoring support for it means that we go back to mark build- dependencies as manually installed again by default and provide this option to keep them as automatically installed.
2016-02-10get dpkg lock in build-dep if cache was invalid againDavid Kalnischkies
Regression introduced in a249b3e6fd798935a02b769149c9791a6fa6ef16, which in the case of an invalid cache would build the first part unlocked and later pick up the (still unlocked) cache for further processing, so the system got never locked and apt would end up complaining about being unable to release the lock at shutdown. The far more common case of having a valid cache worked as expected and hence covered up the problem – especially as tests who would have noticed it are simulations only, which do not lock. Closes: 814139 Reported-By: Balint Reczey <balint@balintreczey.hu> Reported-By: Helmut Grohne <helmut@subdivi.de> on IRC
2016-02-03avoid building dependency tree in 'source' commandDavid Kalnischkies
We don't need the dependencies for obvious reasons and we don't need the candidate version either, so building a pkgDepCache is wasted effort, which we can stop doing now that build-dep cleared the path.
2016-02-03use pkgCache::VS instead of pkgDepCache::VS()David Kalnischkies
The later just calls the earlier, but the later needs the fullblown dependency cache to be initialized, which is a very costly operation and isn't done anymore that early in the run as we would need to throw away and rebuild it again after we got all the information about source pkgs. As we end up with a nullptr for the pkgDepCache, we use a slightly longer calling convention to make sure that we use the pkgCache directly, avoiding nullptr induced segfaults and costly operations. Git-Dch: Ignore Reported-By: Balint Reczey <balint@balintreczey.hu>
2016-01-26get sources for packages in multiple releases againDavid Kalnischkies
In 321213f0dcdcdaab04e01663e7a047b261400c9c Andreas Cadhalpun corrected the incorrect overriding of earlier better-fitting results with later (semi-)matches – but that broke the case in which packages are in multiple releases in the same version (and the user has both releases configured). Closes: 812497
2016-01-25reimplement build-dep via apts normal resolverDavid Kalnischkies
build-dep was implemented by parsing the build-dependencies of a package and figuring out which packages to install/remove based on this. That means that for the first level of dependencies build-dep was implementing its very own resolver with all the benefits (aka: bugs) this gives us for not using the existing resolver for all levels. Making this work involves generating a dummy binary package with fitting Depends and Conflicts and as we can't create them out of thin air the cache generation needs to be involved so we end up writing a Packages file which we want to parse – after we have parsed the other Packages files already. With .dsc/.deb files we could add them before we started parsing anything. With a bit of care we can avoid generating too much data we have to throw away again (as many parts assume that e.g. the count of packages doesn't change midair), so that on a speed front there shouldn't be much of a difference, but output can be slightly confusing as if we have a completely valid cache on disk the "Reading package lists... Done" is printed two times – but apt is pretty quick about it in that case. Closes: #137560, #444930, #489911, #583914, #728317, #812173
2016-01-14delay build-dep variable initialisation until neededDavid Kalnischkies
Git-Dch: Ignore
2016-01-02fail installing build-deps if parsing them failedDavid Kalnischkies
Git-Dch: Ignore
2015-12-01require explicit paths to dsc/control as we do for deb filesDavid Kalnischkies
Otherwise a user is subject to unexpected content-injection depending on which directory she happens to start apt in. This also cleans up the code requiring less implementation details in build-dep which is always good. Technically, this is an ABI break as we override virtual methods, but that they weren't overridden was a mistake resulting in pure classes, which shouldn't be pure, so they were unusable – and as they are new in 1.1 nobody is using them yet (and hopefully ever as they are borderline implementation details). Closes: 806693
2015-12-01deal with configured build-essential firstDavid Kalnischkies
There is no need to check configured build-essentials for each package, doing it once at the start ought to be enough. Git-Dch: Ignore
2015-12-01split build-dep satisfier loop out of DoBuildDepDavid Kalnischkies
Lets do this non-behaviour change before we modify the source for real as the reflow and moving would otherwise hide all the interesting changes. Git-Dch: Ignore
2015-11-29do not override exact targetrelease matches with lesser matchesAndreas Cadhalpun
The relevant testcases are in test/integration/test-apt-get-source. There is a test for #731853 that is supposed to "ensure that apt will pick the higher version number" of 0.0.1 (stable) and 0.1 (stable). However, this works by pure chance, as simply reversing the order of the two insertsource lines makes the test fail. So #731853 isn't really fixed, yet. Actually, that's related to the problem I reported, as the underlying issue for both is the same: In the FindSrc function apt chooses a new 'best hit', if either * there is a target release and it matches the release of the package, * or the version of the package is higher than the last best hit. Consider having 1.0 (stable), 2.0 (unstable) and 1.5 (unstable), in this order. Looking for the version in stable, apt first selects 1.0, because the release matches the target release, but then subsequently selects 2.0, because the version is higher. Looking for the version in unstable, apt first selects 2.0, because the release matches the target release, but then subsequently selects 1.5, because the release also matches the target release. The correct way would be to choose a new 'best hit', if either * there is a target release and it matches the release of the package, * or there is no target release and the version is higher than the last best hit. Closes: 746412 Mail-Reference: <565A604B.7090104@googlemail.com> Mail-Archive: https://lists.debian.org/debian-devel/2015/11/msg00470.html
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-04hidden support more apt-get/apt-cache commands in aptDavid Kalnischkies
apt is supposed to be a user-friendly interface, so while these commands are usually poweruser material and therefore do not need to be shown in general introduction manpages/help messages its of no use to not allow users to use them. This includes clean, autoclean, build-dep, source, download, changelog, depends, rdepends and showsrc – it doesn't include more non-interactive commands like dump or xvcg as those are usually used by scripts if at all. Closes: 778234, 780700, 781237