| Age | Commit message (Collapse) | Author |
|---|
|
Having dependency data separated from the link between version/package
and the dependency allows use to work on sharing the depdency data a bit
as it turns out that many dependencies are in fact duplicates. How many
are duplicates various heavily with the sources configured, but for a
single Debian release the ballpark is 2 duplicates for each dependency
already (e.g. libc6 counts 18410 dependencies, but only 45 unique). Add
more releases and the duplicates count only rises to get ~6 for 3
releases. For each architecture a user has configured which given the
shear number of dependencies amounts to MBs of duplication.
We can cut down on this number, but pay a heavy price for it: In my
many releases(3) + architectures(3) test we have a 10% (~ 0.5 sec)
increase in cache creationtime, but also 10% less cachesize (~ 10 MB).
Further work is needed to rip the whole benefits from this through, so
this is just the start.
Git-Dch: Ignore
|
|
DepCache functions are called a lot, so if we can squeeze some drops out
of them for free we should do so. Takes also the opportunity to remove
some whitespace errors from these functions.
Git-Dch: Ignore
|
|
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.
|
|
Doing this disables the implicit copy assignment operator (among others)
which would cause hovac if used on the classes as it would just copy the
pointer, not the data the d-pointer points to. For most of the classes
we don't need a copy assignment operator anyway and in many classes it
was broken before as many contain a pointer of some sort.
Only for our Cacheset Container interfaces we define an explicit copy
assignment operator which could later be implemented to copy the data
from one d-pointer to the other if we need it.
Git-Dch: Ignore
|
|
Some of them modify the ABI, but given that we prepare a big one
already, these few hardly count for much.
Git-Dch: Ignore
|
|
We used to read the Release file for each Packages file and store the
data in the PackageFile struct even through potentially many Packages
(and Translation-*) files could use the same data. The point of the
exercise isn't the duplicated data through. Having the Release files as
first-class citizens in the Cache allows us to properly track their
state as well as allows us to use the information also for files which
aren't in the cache, but where we know to which Release file they
belong (Sources are an example for this).
This modifies the pkgCache structs, especially the PackagesFile struct
which depending on how libapt users access the data in these structs can
mean huge breakage or no visible change. As a single data point:
aptitude seems to be fine with this. Even if there is breakage it is
trivial to fix in a backportable way while avoiding breakage for
everyone would be a huge pain for us.
Note that not all PackageFile structs have a corresponding ReleaseFile.
In particular the dpkg/status file as well as *.deb files have not. As
these have only a Archive property need, the Component property takes
over this duty and the ReleaseFile remains zero. This is also the reason
why it isn't needed nor particularily recommended to change from
PackagesFile to ReleaseFile blindly. Sticking with the earlier is
usually the better option.
|
|
While it is mostly busywork to rewrite all instances it actually fixes
bugs as the data storage used by the new method is std::string rather
than a char*, the later mostly created by c_str() from a std::string
which the caller has to ensure keeps in scope – something apt-ftparchive
actually didn't ensure and relied on copy-on-write behavior instead
which c++11 forbids and hence the new default gcc abi doesn't use it.
|
|
Slightly rewriting the code to ensure we only use two sources for the
versions as it could otherwise be confusing to look at.
|
|
Unlikely perhaps, but there is no guarantee that the directory we want
to drop the file into actually exists, so create it if we must.
|
|
Having it in the header exposes some implementation details, namely
private methods and will cause problems for us if we ever want to change
the actions.
Git-Dch: Ignore
|
|
Conflicts:
apt-pkg/acquire-item.cc
configure.ac
debian/changelog
doc/apt-verbatim.ent
doc/po/apt-doc.pot
doc/po/de.po
doc/po/es.po
doc/po/fr.po
doc/po/it.po
doc/po/ja.po
doc/po/pt.po
po/ar.po
po/ast.po
po/bg.po
po/bs.po
po/ca.po
po/cs.po
po/cy.po
po/da.po
po/de.po
po/dz.po
po/el.po
po/es.po
po/eu.po
po/fi.po
po/fr.po
po/gl.po
po/hu.po
po/it.po
po/ja.po
po/km.po
po/ko.po
po/ku.po
po/lt.po
po/mr.po
po/nb.po
po/ne.po
po/nl.po
po/nn.po
po/pl.po
po/pt.po
po/pt_BR.po
po/ro.po
po/ru.po
po/sk.po
po/sl.po
po/sv.po
po/th.po
po/tl.po
po/tr.po
po/uk.po
po/vi.po
po/zh_CN.po
po/zh_TW.po
test/integration/test-ubuntu-bug-346386-apt-get-update-paywall
|
|
All other counters are correctly initialized here, expect this one. The
practical effect is low as in apt we usually just do "!= 0" checks, but
only correct counters are good counters.
Closes: 758397
|
|
A version belongs to a section and has hence a section member of its
own. A package on the other hand can have multiple versions from
different sections. This was "solved" by using the section which was
parsed first as order of sources.list defines, but that is obviously a
horribly unpredictable thing.
We therefore directly remove this struct member to free some space and
mark the access method as deprecated, which is told to return the
section of the 'newest' known version, which is at least predictable,
but possible not what it returned before – but nobody knows.
Users are way better of with the Section() as returned by the version
they are dealing with. It is likely the same for all versions of a
package, but in the few cases it isn't, it is important (like packages
moving from main/* to contrib/* or into oldlibs …).
|
|
In commit 21b3eac8 I promoted the check for installable dependencies to
a pre-install check, which also reverts to a known good candidate (the
installed version) if it fails. This revert was done even for user
requested candidate switches which disabled our Broken detection so that
install requests which are impossible to satisfy do not fail anymore,
but print an (incomplete) solution proposal and then exit successfully.
Closes: 745046
|
|
Fix incorrect cast in pkgDepCache::Policy::GetCandidateVer()
Reported-By: clang -fsanitize=address -fno-omit-frame-pointer
|
|
In commit 446551c8 I changed MarkInstall to discard the candidate if the
candidate can't satisfy the dependency. This breaks interactive solvers
like aptitude which can change the candidate on-the-fly later.
In commit df77d8a5 I introduced this 'early' loop-breaking to begin with
which can't be that helpful for interactive solvers as well, but makes
perfect sense for non-interactives to stop them from exploring trees
which can't be satisfied, but it isn't perfect as ideally we would check
this before auto-installing the first dependency.
This commit therefore moves the loop into its own IsInstallOk hook so
that frontends can override this check if they want to and in exchange
removes the loop-breaking from MarkInstall itself and does it before any
dependency is installed.
Closes: 740750
|
|
Hooked checks could be influenced by AutoInst as a lot can happen
between a call without and one with this bit set. The real cache-hit
check is above this call already. Individual hooked checks can then
inspect the state if they want to cache. Calling them multiple times
shouldn't be a problem either way.
|
|
Git-Dch: Ignore
Reported-By: gcc -Wsuggest-attribute={pure,const,noreturn}
|
|
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)
|
|
Reported-By: gcc -Wunused-parameter
Git-Dch: Ignore
|
|
Git-Dch: Ignore
Reported-By: gcc -Wmissing-declarations
|
|
Git-Dch: Ignore
Reported-By: gcc -Wpedantic
|
|
|
|
|
|
If a (Pre-)Depends can't be satisfied there is no point in keeping the
candidate as is as it is impossible to find a solution for it, so we can
just as well reset the candidate to the currently installed version.
We avoid trying to install this impossible candidate later on this way.
Closes: #735967
|
|
When checking for negative dependencies in MarkInstall() ensure that
only dependencies that are relevant (i.e. getting installed) are
checked.
|
|
|
|
We can't remove packages which are held back by the user with a hold, so
marking them (or its dependencies) as garbage will lead our autoremover
into madness – and given that the package is important enough that the
user has held it back it can't be garbage (at least at the moment), so
even if a front-end wants to use the info just for information display
its a good idea to not consider it garbage for them.
Closes: 724995
|
|
The rational from the buglog:
> The problem here is that the Priority field in one of the Packages files
> is incorrect due to a mishap with reprepro configuration, […] the
> amd64 version is Priority: standard but the arm64 version is Priority:
> optional (and has a stray "optional: interpreters" field).
> […]
> However, Priority is a rather weak property of a package because it's
> typically applied via overrides, and it's easy for maintainers of
> third-party repositories to misconfigure them so that overrides aren't
> applied correctly. It shouldn't be ranked ahead of choosing packages
> from the native architecture. In this case, I have no user-mode
> emulation for arm64 set up, so choosing m4:arm64 simply won't work.
This effectly makes the priority the least interesting data point in
chosing a provider, which is in line with the other checks we have
already order above priority in the past and also has a certain appeal by
the soft irony it provides.
Closes: #718482
|
|
Multi-Arch: same packages can be co-installed, but need to have the same
version for all installed packages (aka "siblings"). Otherwise the
unsynced versions will fight against each other and the auto-install as
wel as the problem resolver will later have to decide between holding the
packages or to remove one of the siblings (usually a foreign) taking a
bunch of packages (like the entire foreign setup) with them.
The idea here is now to be more pro-active: MarkInstall will fail for
a package if the siblings aren't synced, so we don't allow a situation
in which a resolver has to decide if to hold or to remove-upgrade under
the assumption that the remove-upgrade decision is always wrong and
doesn't deserve to be explored (expect valid out-of-syncs of course).
Thats a pretty bold move to take for a library which is used by
different solvers so this check is done in IsInstallOk and can be
overridden if front-ends want to.
|
|
Conflicts:
debian/changelog
|
|
debug output of Debug::pkgDepCache::AutoInstall=true
|
|
|
|
Used to work until a certain (here unnamed) person came along and used
the wrong operator causing low-priority packages to be sorted above
high-priority packages while choosing a provider in commit
2b5c35c7bb915dbd46fefd7c79f05364ba22f93b from Nov 2011
|
|
- provide DepIterator::IsSatisfied as a nicer shorthand for DepCheck
|
|
- prefer to install packages which have an already installed M-A:same
sibling while choosing providers (LP: #1130419)
|
|
|
|
- don't call MarkInstall with the FromUser flag set for packages
which are dependencies of APT::Never-MarkAuto-Sections matchers
|
|
- ignore negative dependencies applying in the same group for
M-A:same packages on the real package name as self-conflicts
|
|
version (or none as we have no versioned provides in debian) and not
if the version of the provider matches
|
|
- clearly separate 'positive' and 'negative' dependencies and
their upgrade-resolution tries in MarkInstall and especially don't
treat Conflicts differently compared to Breaks here
|
|
- No Immediate configuration (see above)
- Not automatically installed during dist-upgrade
|
|
- if a M-A:same package is marked for reinstall, mark all it's installed
silbings for reinstallation as well (LP: #859188)
|
|
|
|
- implicit conflicts (for multiarch) are supposed to conflict
only with real packages, not with virtual providers
|
|
- prefer native providers over foreigns even if the chain is foreign
The code preferred real over virtual packages and based on priorities.
This is changed in so far that a real package from any arch is preferred
over any virtual provider and if priorities doesn't help in choosing the
best provider we choose it based on architectures
|
|
|
|
|
|
|
|
size are pretty unlikely for now, but we need it for deb
packages which could become bigger than 4GB now (LP: #815895)
|
