| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
Strange things happen if while resolving the dependencies of a package
said dependencies want to remove the package. The allow-scores test e.g.
removed the preferred alternative in favor of the last one now that they
were exclusive. In our or-group for Recommends we would "just" not
statisfy the Recommends and for Depends we engage the ProblemResolver…
|
| |
|
|
|
|
|
|
| |
In normal upgrade scenarios this is no problem as the orgroup member
will be marked for upgrade already, but on a not fully upgraded system
(or while you operate on a different target release) we would go with our
usual "first come first serve" approach which might lead us to install
another provider who comes earlier – bad if the providers conflict.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a package is protected and has a dependency satisfied only by a single
package (or conflicts with a package) this package must be part of the
solution and so we can help later actions not exploring dead ends by
propagating the protected flag to these "pseudo-protected" packages.
An (obscure) bug this can help prevent (to some extend) is shown in
test-apt-never-markauto-sections by not causing irreversible autobit
transfers.
As a sideeffect it seems also to help our crude ShowBroken to display
slightly more helpful messages involving the packages which are actually
in conflict.
|
| |
|
|
|
|
|
|
| |
MarkDelete is not recursive as MarkInstall is and we can not conflict
with ourselves anyhow, so we can move the unavoidable deletes before
changing the state of the package in question avoiding the need for the
state update in case of conflicts we can not deal with (e.g. the package
conflicts with an explicit user request).
|
| |
|
|
|
| |
Should be easier to move the code bits around then and it helps in
documenting a bit what the blocks do and how they interact (or not).
|
| |
|
|
|
|
| |
We do pretty much the same in IsInstallOk, but here we have already set
the state, so we have to unroll the state as well to sort-of replicate
the state we were in before this MarkInstall failed.
|
| |
|
|
|
|
|
| |
This fixes no bugs per se, but the idea is to delay more costly changes
and check easier things first. It e.g. inhibits the moving of the
autobit until we are sure that this MarkInstall call isn't going to
fail (e.g. because a dependency isn't satisfiable).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
MarkInstall only looks at the first alternative in an or-group which has
a fighting chance of being satisfiable (= the package itself satisfies
the dependency, if it is installable itself is not considered).
This is "hidden" for Depends by the problem resolver who will try
another member of the or-group later, but Recommends are not a problem
for it, so for them the alternatives are never further explored.
Exploring the or-group in MarkInstall seems like the better choice for
both types as that frees the problem resolver to deal with the hard
things like package conflicts.
|
| |
|
|
|
|
|
|
| |
We reseted the candidate for installed packages back to the version
which is installed if one of the (critical) dependencies of it is not
statisfiable, but we can do the same for non-installed packages by
discarding the candidate which beside slightly helping the resolver also
improves error messages generated by apt as a sideeffect.
|
| | |
|
| |
|
|
|
|
|
|
| |
No user-visible change as it effects mostly code comments and
not a single error message, manpage or similar.
Reported-By: codespell & spellintian
Gbp-Dch: Ignore
|
| |
|
|
|
|
|
|
|
|
|
| |
When running with Debug::pkgAutoRemove=yes, explain why certain packages
are being marked, either because they're marked essential/important or
because they match the blacklist from APT::NeverAutoRemove.
This should help troubleshoot cases where autoremove is not proposing
removal of packages expected to be up for removal.
Tested manually with `apt-get autoremove -o Debug::pkgAutoRemove=yes`.
|
| |
|
|
| |
Prompted-by: Jakub Wilk <jwilk@debian.org>
|
| |
|
|
|
| |
Reported-By: codespell & spellintian
Gbp-Dch: Ignore
|
| |
|
|
|
|
|
| |
If we perform candidate switching in requests like "apt install foo/bar"
we should first check if the dependencies of foo from release bar are
already satisfied by what is already installed before checking if the
candidate (or switched candidate) would.
|
| |
|
|
|
| |
As a follow up to the last commit, let's replace APT_CONST
with APT_PURE everywhere to clean stuff up.
|
| |
|
|
|
|
| |
This file isn't compressed by default, but it might be compressed by a
bugreporter and uncompressing it is extra work apt could do just as well
on the fly as needed just like it does for the dpkg/status file.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This makes it easier to see which headers includes what.
The changes were done by running
git grep -l '#\s*include' \
| grep -E '.(cc|h)$' \
| xargs sed -i -E 's/(^\s*)#(\s*)include/\1#\2 include/'
To modify all include lines by adding a space, and then running
./git-clang-format.sh.
|
| |
|
|
|
| |
Including cacheiterators.h before pkgcache.h fails because
pkgcache.h depends on cacheiterators.h.
|
| |
|
|
|
| |
Reported-By: codespell & spellintian
Gbp-Dch: Ignore
|
| |
|
|
|
|
|
|
| |
Most of them in (old) code comments. The two instances of user visible
string changes the po files of the manpages are fixed up as well.
Gbp-Dch: Ignore
Reported-By: spellintian
|
| |
|
|
|
|
|
|
|
|
| |
The existing cleanup was happening only for packages which had a status
change (install -> uninstalled) which is the most frequent but no the
only case – you can e.g. set autobits explicitly with apt-mark.
This would leave stanzas in the states file declaring a package to be
manually installed – which is the default value for a package not listed
at all, so we can just as well drop it from the file.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Traditionally all providers are protected providing something as apt
can't know which of them is actually really providing the functionality
for the user ensuring that we don't propose the removal of used stuff,
but that is of course also keeping stuff around which could be removed.
That can cause the collection of multiple old providers until the
provided package is itself no longer needed (e.g. out-of-tree kernel
modules). We combat this by marking providers only from the newest
source package version so that old providers built by older versions of
the same source package can be garbage collected.
|
| |
|
|
|
|
|
|
| |
As the previous commit, this shouldn't change behavior at all, but
beside being more explicit and perhaps faster its also considerably
shorter (granted, mostly by if0-block elimination).
Gbp-Dch: Ignore
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Piling everything in a single if statement always made my head wobble,
but it hasn't even a benefit as the most common case of a package which
isn't installed passes all of the old if and lands in the non-existent
else-part of the inner if. So beside a subjective cleanup of what goes
on this implementation should also be a bit faster.
No change in behavior should be present.
Gbp-Dch: Ignore
|
| |
|
|
|
|
|
|
| |
If we can't read the old file we can't just move forward as that would
discard potentially discard old data (especially other fields). We let
it fail only after we are done writing the new file so a user has the
chance to look into and merge the new data (which is otherwise
discarded).
|
| |
|
|
|
|
|
|
|
| |
The old prettyprinters have only access to the struct they pretty print,
which isn't enough usually as we want to know for a package also a bit
of state information like which version is the candidate.
We therefore need to pull the DepCache into context and hence use a
temporary struct which is printed instead of the iterator itself.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Using Pkg.CandVersion() here is wrong as its implementation will return
a candidate based just on the default policy settings ignoring user
preferences and otherwise set candidates (aka: it sidesteps the
pkgDepCache).
This causes M-A:same libraries to be detected as screwed even through
they aren't, so that they end up being kept back.
Reported-By: Felipe Sateler on IRC
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the package is marked for removal, keep it marked for
removal and do not mark it for keep. If we mark it for keep,
we some how later get to a different stage where it is marked
for unpack instead of removal.
In the example in the bug report, we would get a:
SmartUnPack maas-region-controller-min:amd64 (replace version 2.0.0~alpha3+bzr4810-0ubuntu1 with Segmentation fault
maas-region-controller-min:amd64 was marked for removal, but
we changed it to keep and somehow it thinks that this is to
be replaced now instead of removed (probably because the
InstallVer != CandidateVer [with InstallVer = 0]).
This fixes a regression introduced in release 1.2.7, commit:
0390edd5452b081f8efcf412f96d535a1d959457
Reported-by: LaMont Jones on IRC
LP: #1562402
|
| |
|
|
|
|
|
|
|
|
|
| |
The epoch stripping in this code is done since day one, but in other
places we show a version epochs are not stripped. If epochs are present
in packages they tend to be an important information which we can't just
drop and especially can't drop "sometimes" as that confuses users and
tools alike – so even if removing code in use for (close to) 18 years
feels wrong, it is probably the right choice for consistency.
Closes: 818162
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The problemresolver will set the candidate version for pkg P back
to the current version if it encounters an impossible to satisfy
critical dependency on P. However it did not set the State of
the package back as well which lead to a situation where P is
neither in Keep,Install,Upgrade,Delete state.
Note that this can not be tested via the traditional sh based
framework. I added a python-apt based test for this.
LP: #1550741
[jak@debian.org: Make the test not fail if apt_pkg cannot be
imported]
|
| |
|
|
|
|
|
|
| |
If you have chosen to install a foreign architecture provider it is
more reasonable to keep this provider instead of removing this one to
replace it with a newer version from a (usually) more preferred arch.
Git-Dch: Ignore
|
| |
|
|
|
|
| |
The manpages were fixed by Justin B Rye, lets deal with the rest now.
Git-Dch: Ignore
|
| |
|
|
|
|
|
|
|
| |
This was discussed a while ago on #debian-apt and now that I see myself
making this mistake lets bite the bullet and fix it in the easy way out
version: Using a new name which fits with a similar named setter and
deprecate the old method instead of 'hostily' changing API.
Closes: #803471
|
| | |
|
| |
|
|
|
|
|
| |
Also unify the case of considerFiles and ConsiderFiles to be
ConsiderFiles in all cases.
Gbp-Dch: ignore
|
| |
|
|
| |
More standardization
|
| |
|
|
| |
This is nicer
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
oldlibs used to be in APT::Never-MarkAuto-Sections so that old
transition packages can be removed without causing the then
(autoinstalled) renamed package to be autoremoved. It isn't ideal
through as ideally you want the oldlibs package to be removed after
nothing depends on it anymore regardless of if you have once installed
it by hand or not – and if you had the package talking over (the
dependencies) should carry the manual bit now as they are the real deal
now.
As an added bonus if the package has no dependencies because it is an
oldlibs without a direct replacement you should move away from (like
lib1 and lib2 are currently in the archive, but there will hopefully
only be lib2 in the release) you get a lib1 marked as auto.
If the user still needs the oldlibs package for some reason all he has
to do is mark it as manual once as this move is only performed if a
installed package changes its section from a not-Move-Autobit-Sections
to a Move-Autobit-Sections.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Having the handling in MarkInstall means that it just effects
installation of the metapackage, but if the dependencies change the new
dependencies aren't protected (and the old dependencies are still
protected for no 'reason'). Having it in MarkDelete means that if a
metapackage is sheduled for removal all its currently installed
dependencies are marked as manual, which helps against both as in this
case there is no new/old and additionally if a user decides the
installation of a metapackage was wrong he can just remove it
explicitely avoid the manual marking entirely.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In 50ef3344c3afaaf9943142906b2f976a0337d264 (and similar for other
branches), while 'fixing' the edgecase of a package being in multiple
sections (e.g. moved from libs to oldlibs in newer releases) I
accidently broke the feature itself completely by operating on the
package itself and no longer on its dependencies…
The behaviour isn't ideal in multiple ways, which we are hopefully able
to fix with new ideas as mentioned in the buglog, but until then the
functionality of this "hack" should be restored.
Reported-By: Raphaël Hertzog <hertzog@debian.org>
Tested-By: Adam Conrad <adconrad@ubuntu.com>
Closes: 793360
LP: 1479207
Thanks: Raphaël Hertzog and Adam Conrad for detailed reports and initial patches
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|