Story #2788
Updated by rmcgover almost 7 years ago
When a yum repo is published, and sqlite generation is enabled (generate_sqlite=true), and incremental publish is activated (i.e. force_full is not true and units were not deleted since last publish), new sqlite files will be created and old sqlite files will be retained. Since the old sqlite files are never cleaned, this means that the published repodata of a repo will keep all old sqlite files since the last non-incremental publish, which wastes space and makes publishes slower. Steps to reproduce: * Create repo, ensure it has a yum_distributor with generate_sqlite: true * Add RPM to repo * Publish repo * Note count of *-primary.sqlite.bz2 files in published repo * Add RPM to repo * Publish repo * Note count of *-primary.sqlite.bz2 files in published repo Actual result: * After first publish, 1 primary sqlite file exists * After second publish, 2 primary sqlite files exist Expected result: * After first publish, 1 primary sqlite file exists * After second publish: ** * If https://pulp.plan.io/issues/1684 is implemented, sqlite files should be subject to the configured retention options. Thus it depends on the age of the existing sqlite file. ** * Otherwise, to be consistent with XML handling, the old sqlite files should probably be deleted, so only 1 primary sqlite file exists.
.