| Age | Commit message (Collapse) | Author |
|---|
|
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.
(cherry picked from commit 84573326f41dd09b914b8374548e7ee7c93d0439)
|
|
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).
(cherry picked from commit 520931867ee2fac8415a624204414d3b62550996)
|
|
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.
|
|
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
|
