Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.2.6 2015-11-25T14:20:10Z 2015-11-25T14:20:10Z David Kalnischkies david@kalnischkies.de 2015-11-22T18:02:13Z urn:sha1:ab5b1d0d31b2fbdc4896f8a107611ff056d6a668 Never updating this information is wrong, updating it automatically isn't super correct either, but it seems conventional to have it and updating it more often than needed seems better than updating it never. Git-Dch: Ignore 2015-11-04T17:04:05Z David Kalnischkies david@kalnischkies.de 2015-10-27T08:57:26Z urn:sha1:8561c2fedae26aecd8ba758a5e7ef686ba1243f3 The general idea is: A small paragraph on the tool itself as a description, a list of the most used (!= all) commands available in the tool, a remark where to find more information on the tool and its commands (aka: in the manpage) and finally a common block referring to even more manpages. In exchange options are completely omitted from the output as well as deprecated or obscure commands. (Better) Information about them is available in the manpages anyway and the few options which were listed before were also the least interesting ones (-o -c -q and co are hardly of interest for someone totally new looking to find info by asking for help and anyone with a bit of experience doesn't need this short list. Those would need a list of options applying to the command they call, but they are too numerous and command specific to list them sanely in this context. 2015-08-18T18:39:59Z Michael Vogt mvo@debian.org 2015-08-18T18:39:59Z urn:sha1:a8275acf87cf15992e6b89694d6276e0a5e529b9 Thanks: Steve Slangasek for the suggestion Closes: 695633 2015-08-14T20:43:00Z Julian Andres Klode jak@debian.org 2015-08-14T20:43:00Z urn:sha1:dd5978bff4d0bea85b3adbf52a194afd25a655b3 Closes: #691281 2015-08-14T14:57:02Z Julian Andres Klode jak@debian.org 2015-08-14T14:57:02Z urn:sha1:5fba9462b635c95d2cb329a388d469bd50889974 Closes: #618017 2015-08-10T15:27:58Z David Kalnischkies david@kalnischkies.de 2015-07-16T09:15:25Z urn:sha1:8c7af4d4c95d0423fbd0f3baa979792504f4f45f Before MultiArch implicits weren't a thing, so they were hidden by default by definition. Adding them for MultiArch solved many problems, but having no reliable way of detecting which dependency (and provides) is implicit or not causes problems everytime we want to output dependencies without confusing our observers with unneeded implementation details. The really notworthy point here is actually that we keep now a better record of how a dependency came to be so that we can later reason about it more easily, but that is hidden so deep down in the library internals that change is more the problems it solves than the change itself. 2014-08-26T18:49:48Z David Kalnischkies david@kalnischkies.de 2014-07-18T14:42:40Z urn:sha1:5abbf5bbb5ee8717f89cac6ef409c4cec79259f6 Not all are needed for all files at the moment, but the new docbook building hadn't available some of the entities it used as the files weren't correctly copied around in all cases and having the same across the bord makes working with all of them a little easier. Git-Dch: Ignore 2013-11-30T22:34:15Z David Kalnischkies kalnischkies@gmail.com 2013-11-30T18:15:02Z urn:sha1:694ef56e802bbab94595fc491fdc6ef8b4f525c1 manpages sometimes refer to distro-specific things like the name of the package providing the achive-keyring. Having a central place to configure this helps in having it consistent in the manpages and allows to load this info from other places in the buildsystem as well later. 2012-06-09T20:05:55Z David Kalnischkies kalnischkies@gmail.com 2012-06-09T20:05:55Z urn:sha1:dabb215cb8c4b074d286737da523d8ef14381468 2012-05-24T14:00:53Z Justin B Rye jbr@edlug.org.uk 2012-05-24T14:00:53Z urn:sha1:1d254cb23a090f69ea53c740dd988e99ee13a247 - three small rewordings for better english sentences