Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=master 2016-01-25T17:15:44Z 2016-01-25T17:15:44Z David Kalnischkies david@kalnischkies.de 2016-01-21T22:22:00Z urn:sha1:a249b3e6fd798935a02b769149c9791a6fa6ef16 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 2015-12-19T22:04:34Z David Kalnischkies david@kalnischkies.de 2015-12-15T16:20:26Z urn:sha1:3abb6a6a1e485b3bc899b64b0a1b7dc2db25a9c2 This doesn't allow all tests to run cleanly, but it at least allows to write tests which could run successfully in such environments. Git-Dch: Ignore 2015-12-02T11:59:23Z David Kalnischkies david@kalnischkies.de 2015-12-02T11:56:04Z urn:sha1:39f96d07cfe61f5e87279a704baed85f1468bc57 'Regression' of 7d19ee92f2368a40e739cb27d22d6d28f37ebf45, just that it now works more as expected than previously. Of course, build-essentials are implicitly also build dependencies, so by definition all packages have build dependencies, but that isn't what this message wants to say and it isn't what the user expects. Git-Dch: Ignore 2015-08-17T16:37:18Z Julian Andres Klode jak@debian.org 2015-08-17T16:37:09Z urn:sha1:e7ebb41440cbe298b07c7fb7c6b20a64a17200f0 Gbp-Dch: ignore 2015-03-16T17:01:54Z David Kalnischkies david@kalnischkies.de 2015-03-09T23:59:44Z urn:sha1:25b86db159fbc3c043628e285c0c1ef24dec2c6e We use test{success,failure} now all over the place in the framework, so its only consequencial to do this in the situations in which we test for a specific output as well. Git-Dch: Ignore 2014-09-07T17:28:21Z David Kalnischkies david@kalnischkies.de 2014-09-07T17:28:21Z urn:sha1:e9bb097c914ff4fb1cdeda8a2843644dca184c56 Using 'kfreebsd' here makes the test fail on a kfreebsd system (obviously), so we just use something totally madeup in the hope that this is less like to conflict in the future. Git-Dch: Ignore 2014-02-10T17:07:49Z David Kalnischkies david@kalnischkies.de 2014-02-06T19:48:52Z urn:sha1:a7250ed08e4761dd40870ea7350ca2c83457e890 Git-Dch: Ignore 2012-07-12T18:39:59Z David Kalnischkies kalnischkies@gmail.com 2012-07-12T18:39:59Z urn:sha1:5f20ac7f11ae5718595d6e570474d120d30e36db - remove architecture-specific arch to tuple expansion-rules as they lead to the same tuples for different architectures (e.g. linux-arm for arm, armel and armhf) while the dpkg-architecture code uses triples which are different (in the first part, which we omit in our tuples), so e.g. build-dep restrictions for armel ended up effecting armhf as well 2012-06-14T17:07:15Z David Kalnischkies kalnischkies@gmail.com 2012-06-14T17:07:15Z urn:sha1:01f520ce27c7f466dc6191c45507ace79d685725