summaryrefslogtreecommitdiff
path: root/apt-pkg/cachefile.cc
Commit message (Collapse)AuthorAgeFilesLines
* fail instead of segfault on unreadable config filesDavid Kalnischkies2016-05-201-0/+3
| | | | | | | | | | | | | The report mentions "apt list --upgradable", but there are others which have inconsistent behavior ranging from segfaulting to doing something with the partial (and hence incomplete) data. We had a recent report about sources.list (#818628), this one mentions prefences, the obvious next step is conf files… so the testcase is adapted to check for all three in file and directory versions and run a bunch of commands each time which should all have more or less the same behavior in such a case (aka error out). Closes: 824503
* cachefile: Only set members that were initialized successfullyJulian Andres Klode2016-03-191-16/+46
| | | | | | | | | | | Otherwise, things will just start failing later down the stack, because (a) the lazy getters do not check if building was successful and (b) any further getter call would return the invalid object anyway. Also initialize VS in pkgCache to nullptr by default. Closes: #818628
* get dpkg lock in build-dep if cache was invalid againDavid Kalnischkies2016-02-101-0/+1
| | | | | | | | | | | | | | | | 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
* deal better with (very) small apt::cache-start valuesDavid Kalnischkies2016-01-271-1/+1
| | | | | | | | | It is a bit academic to support values which aren't big enough to fit even the hashtables without resizing, but cleaning up ensures that we do the right thing (aka not segfaulting) even if something goes wrong in these deep layers. You still can't have very very small values through… Git-Dch: Ignore
* reimplement build-dep via apts normal resolverDavid Kalnischkies2016-01-251-0/+55
| | | | | | | | | | | | | | | | | | | | | | | | 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
* pkgCacheGenerator: Allow passing down an already created cacheJulian Andres Klode2015-12-291-2/+4
| | | | | If we already have opened a cache, there is no point in having to open it again.
* do not segfault in cache generation on mmap failureDavid Kalnischkies2015-11-201-0/+2
| | | | | | | | | | | | | | | Out of memory and similar circumstanzas could cause MMap::Map to fail and especially the mmap/malloc calls in it. With some additional checking we can avoid segfaults and similar in such situations – at least in theory as if this is a real out of memory everything we do to handle the error could just as well run into a memory problem as well… But at least in theory (if MMap::Map is made to fail always) we can deal with it so good that a user actually never sees a failure (as the cache it tries to load with it fails and is discarded, so that DynamicMMap takes over and a new one is build) instead of segfaulting. Closes: 803417
* wrap every unlink call to check for != /dev/nullDavid Kalnischkies2015-11-041-4/+4
| | | | | | | | | | | | | | | | Unlinking /dev/null is bad, we shouldn't do that. Also, we should print at least a warning if we tried to unlink a file but didn't manage to pull it of (ignoring the case were the file is /dev/null or doesn't exist in the first place). This got triggered by a relatively unlikely to cause problem in pkgAcquire::Worker::PrepareFiles which would while temporary uncompressed files (which are set to keep compressed) figure out that to files are the same and prepare for sharing by deleting them. Bad move. That also shows why not printing a warning is a bad idea as this hide the error for in non-root test runs. Git-Dch: Ignore
* avoid using global PendingError to avoid failing too often too soonDavid Kalnischkies2015-09-141-7/+10
| | | | | | | | | | | | | | | | | | | Our error reporting is historically grown into some kind of mess. A while ago I implemented stacking for the global error which is used in this commit now to wrap calls to functions which do not report (all) errors via return, so that only failures in those calls cause a failure to propergate down the chain rather than failing if anything (potentially totally unrelated) has failed at some point in the past. This way we can avoid stopping the entire acquire process just because a single source produced an error for example. It also means that after the acquire process the cache is generated – even if the acquire process had failures – as we still have the old good data around we can and should generate a cache for (again). There are probably more instances of this hiding, but all these looked like the easiest to work with and fix with reasonable (aka net-positive) effects.
* ignore AllowMem parameter in cache generationDavid Kalnischkies2015-08-271-5/+2
| | | | | | | | | | | | | | | | The parameter name suggests that it should forbid the building of the entire cache in memory, but this isn't how it was previously and as AllowMem is false by default it actually prevents previous usecases from working like being root and configuring apt to build no caches at all. This should be fixed at some point to actually work, but that is hard to pull off as it means switching the default and some callers (including apt itself) actually did call it explicitly with false in certain cases for no apparent reason (at least now where it is common to have enough memory to throw at every problem and even if not is a slow apt usally better than an apt erroring out). Closes: 796459
* cachefile.cc: Do not ignore return value of pkgDepCache::Init()Julian Andres Klode2015-08-151-2/+1
| | | | | | | Currently, this always returns true, but it might start returning false at some point in the future... Gbp-Dch: ignore
* show or-groups in not-installed recommends and suggests listsDavid Kalnischkies2015-08-101-11/+23
| | | | | | | | Further abstracting our new ShowList allows to use it for containers of strings as well giving us the option to implement an or-groups display for the recommends and suggests lists which is a nice trick given that it also helps with migrating the last remaining other cases of old ShowList.
* fix memory leaks reported by -fsanitizeDavid Kalnischkies2015-08-101-2/+2
| | | | | | | | Various small leaks here and there. Nothing particularily big, but still good to fix. Found by the sanitizers while running our testcases. Reported-By: gcc -fsanitize Git-Dch: Ignore
* Ensure we have a Policy in CacheFile.BuildDepCache()Michael Vogt2014-09-051-0/+3
| | | | | | This partly reverts d059cc2 and fixes bug #753297 in a more general way by ensuring that CacheFile.BuildDepCache() builds a pkgPolicy if there isn't one already.
* cleanup headers and especially #includes everywhereDavid Kalnischkies2014-03-131-1/+8
| | | | | | | | Beside being a bit cleaner it hopefully also resolves oddball problems I have with high levels of parallel jobs. Git-Dch: Ignore Reported-By: iwyu (include-what-you-use)
* warning: unused parameter ‘foo’ [-Wunused-parameter]David Kalnischkies2014-03-131-2/+2
| | | | | Reported-By: gcc -Wunused-parameter Git-Dch: Ignore
* fix a bunch of cppcheck "(warning) Member variable '<#>' is notDavid Kalnischkies2012-03-041-1/+1
| | | | initialized in the constructor." messages (no functional change)
* ensure that the cache-directories are really directories beforeDavid Kalnischkies2012-02-181-2/+2
| | | | trying to get a list of included files from them
* * apt-pkg/cachefile.cc:David Kalnischkies2012-02-111-0/+34
| | | - clean up lost atomic cachefiles with 'clean' (Closes: #650513)
* use forward declaration in headers if possible instead of includesDavid Kalnischkies2011-09-191-0/+1
|
* merge with debian/sidDavid Kalnischkies2011-09-131-0/+14
|\
| * remove the caches in 'apt-get update', too, as they will beDavid Kalnischkies2011-08-221-0/+14
| | | | | | invalid in most cases anyway
* | reorder includes: add <config.h> if needed and include it at firstDavid Kalnischkies2011-09-131-1/+3
|/
* fix the gcc warning about the initialisation order of variables causedDavid Kalnischkies2010-06-191-1/+1
| | | | by moving Policy to public again (and therefore after SrcList)
* store also the SourceList we use internally for exportDavid Kalnischkies2010-06-041-12/+46
|
* * apt-pkg/cachefile.{cc,h}:David Kalnischkies2010-06-041-14/+36
| | | | - split Open() into submethods to be able to build only parts - make the OpProgress optional in the Cache buildprocess
* display warnings instead of errors if the parts dirs doesn't existDavid Kalnischkies2009-07-151-1/+3
| | | | | Parts dirs are /etc/apt/{sources.list,apt.conf,preferences}.d (in the default setup)
* merge with lp:~mvo/apt/debian-sidDavid Kalnischkies2009-07-151-1/+1
|\
| * Support /etc/apt/preferences.d (Closes: #535512)Julian Andres Klode2009-07-061-1/+1
| |
* | add the various foldmarkers in apt-pkg & cmdline (no code change)David Kalnischkies2009-06-301-3/+0
|/
* * move the ListUpdate() code from cachefile.h into algorithms.{cc,h}Michael Vogt2008-01-071-74/+0
| | | | as it does not require a cachefile at all
* support optional PulseInterval in ListUpdateMichael Vogt2008-01-041-3/+11
|
* * merged the apt--DoListUpdate branch, this provides a common interfaceMichael Vogt2008-01-041-0/+69
|\ | | | | | | for apt-get update like operations for the frontends and also provides hooks to run stuff in APT::Update::{Pre,Post}-Invoke
| * * apt-pkg/deb/dpkgpm.cc, apt-pkg/contrib/fileutl.{cc,h}:Michael Vogt2006-06-071-0/+6
| | | | | | | | | | | | - move the RunScripts() code into fileutl.{cc,h} * apt-pkg/cachefile.cc: - add support for "APT::Update::{Pre,Post}-Invoke" scripts
| * * apt-pkg/cachefile, cmdline/apt-get.cc:Michael Vogt2006-06-071-0/+46
| | | | | | | | - move the code that does the work from apt-get.cc to pkgCacheFile::ListUpdate()
* | * remove all the remaining #pragma implementationMichael Vogt2007-06-081-4/+0
|/
* 'apt-get update' no longer does 'Building Dependency Tree'.Arch Librarian2004-09-201-3/+13
| | | | | | Author: jgg Date: 2002-04-27 04:28:04 GMT 'apt-get update' no longer does 'Building Dependency Tree'.
* Various bug fixesArch Librarian2004-09-201-1/+4
| | | | | | Author: jgg Date: 2001-07-01 20:49:08 GMT Various bug fixes
* Alfredo's vendor stuffArch Librarian2004-09-201-2/+2
| | | | | | Author: jgg Date: 2001-03-13 06:51:46 GMT Alfredo's vendor stuff
* Join with aliencodeArch Librarian2004-09-201-34/+56
| | | | | | Author: jgg Date: 2001-02-20 07:03:16 GMT Join with aliencode
* Various minor bug fixesArch Librarian2004-09-201-2/+2
| | | | | | Author: jgg Date: 1999-06-24 04:06:30 GMT Various minor bug fixes
* Fixed a typoArch Librarian2004-09-201-2/+2
| | | | | | Author: jgg Date: 1999-05-04 20:09:48 GMT Fixed a typo
* Made apt-cache regenerate its cache in memoryArch Librarian2004-09-201-3/+2
| | | | | | Author: jgg Date: 1999-04-19 02:35:38 GMT Made apt-cache regenerate its cache in memory
* Support for memory-only cachingArch Librarian2004-09-201-0/+96
Author: jgg Date: 1999-04-18 06:36:36 GMT Support for memory-only caching
generated by cgit v1.2.3-70-g09d2 (git 2.46.0) at 2024-11-01 04:33:15 +0000