| Age | Commit message (Collapse) | Author |
|---|
|
Git-Dch: Ignore
|
|
Git-Dch: Ignore
|
|
Otherwise a user is subject to unexpected content-injection depending on
which directory she happens to start apt in. This also cleans up the code
requiring less implementation details in build-dep which is always good.
Technically, this is an ABI break as we override virtual methods, but
that they weren't overridden was a mistake resulting in pure classes,
which shouldn't be pure, so they were unusable – and as they are new in
1.1 nobody is using them yet (and hopefully ever as they are borderline
implementation details).
Closes: 806693
|
|
There is no need to check configured build-essentials for each package,
doing it once at the start ought to be enough.
Git-Dch: Ignore
|
|
Lets do this non-behaviour change before we modify the source for real
as the reflow and moving would otherwise hide all the interesting changes.
Git-Dch: Ignore
|
|
The relevant testcases are in test/integration/test-apt-get-source.
There is a test for #731853 that is supposed to "ensure that apt will
pick the higher version number" of 0.0.1 (stable) and 0.1 (stable).
However, this works by pure chance, as simply reversing the order
of the two insertsource lines makes the test fail.
So #731853 isn't really fixed, yet.
Actually, that's related to the problem I reported, as the underlying
issue for both is the same:
In the FindSrc function apt chooses a new 'best hit', if either
* there is a target release and it matches the release of the package,
* or the version of the package is higher than the last best hit.
Consider having 1.0 (stable), 2.0 (unstable) and 1.5 (unstable),
in this order.
Looking for the version in stable, apt first selects 1.0, because the
release matches the target release, but then subsequently selects 2.0,
because the version is higher.
Looking for the version in unstable, apt first selects 2.0, because the
release matches the target release, but then subsequently selects 1.5,
because the release also matches the target release.
The correct way would be to choose a new 'best hit', if either
* there is a target release and it matches the release of the package,
* or there is no target release
and the version is higher than the last best hit.
Closes: 746412
Mail-Reference: <565A604B.7090104@googlemail.com>
Mail-Archive: https://lists.debian.org/debian-devel/2015/11/msg00470.html
|
|
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
|
|
apt is supposed to be a user-friendly interface, so while these commands
are usually poweruser material and therefore do not need to be shown in
general introduction manpages/help messages its of no use to not allow
users to use them.
This includes clean, autoclean, build-dep, source, download, changelog,
depends, rdepends and showsrc – it doesn't include more non-interactive
commands like dump or xvcg as those are usually used by scripts if at
all.
Closes: 778234, 780700, 781237
|
