apt/apt-private/private-source.cc, branch 1.2.10

support APT::Get::Build-Dep-Automatic again in build-dep

2016-03-06T08:39:30Z

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.

get dpkg lock in build-dep if cache was invalid again

2016-02-10T12:03:00Z

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 Reported-By: Helmut Grohne on IRC

avoid building dependency tree in 'source' command

2016-02-03T13:56:49Z

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.

use pkgCache::VS instead of pkgDepCache::VS()

2016-02-03T12:50:00Z

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

get sources for packages in multiple releases again

2016-01-26T20:09:47Z

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

reimplement build-dep via apts normal resolver

2016-01-25T17:15:44Z

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

delay build-dep variable initialisation until needed

2016-01-14T16:33:58Z

Git-Dch: Ignore

fail installing build-deps if parsing them failed

2016-01-02T15:19:40Z

Git-Dch: Ignore

require explicit paths to dsc/control as we do for deb files

2015-12-01T13:26:05Z

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

deal with configured build-essential first

2015-12-01T13:25:28Z

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