| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Nowadays we only download the index file if we have a non-current file
on disk which we want to patch. If that is the case, any index file for
patches we could have stored is by definition outdated, so storing those
files just takes up disk space.
At least, that is the case if we have a Release file – if we don't this
commit introduces a needless redownload for such repositories but such
repositories are an error by default and if they can't be bothered to
provide a Release file its very unlikely they actually ship diffs, so
adding detection code for this seems pointless at best.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The implementation as-is as various smaller/esoteric bugs and
inconsistencies like apt-get not supporting them, the option -s
being supported in code but not accepted on the command line,
the regex not escaping the dot before the file extension and
exposing more implementation details to public headers than we
actually need.
Also comes with a small test case to ensure it actually works.
References: bd7c126e3fb1b94e76e0e632c657cea854586844
|
| |\
| |
| |
| |
| | |
Add 'dist-clean' command to remove packages and list files
See merge request apt-team/apt!290
|
| | |
| |
| |
| |
| |
| |
| | |
We assume all files in the 'listsdir' are candidates. Keep only files
ending with Release, Release.gpg, and InRelease.
Closes: #959093
|
| | |
| |
| |
| |
| |
| | |
This ensures that things work correctly.
LP: #1995790
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
One warning will be issued before the Y/n prompt, the other will
be issued at the end after package installs have been attempted
or if there were other failures, such that the last line you see
is warnings about unmerged-usr
I do not anticipate this to be the final version either, but
there we go.
Closes: #1052058
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
As of bookworm, merged-usr is mandatory, and people got caught
in the crosshairs of the dpkg fsys-unmessusr debacle and inadvertently
reverted back to an unmerged configuration and continue to remain
on an unsupported system unknowingly.
Help them by erroring out when they are installing packages on /,
they are not in a chroot, and a usrmerge package is available.
|
| | |
| |
| |
| |
| |
| |
| | |
We want to gently steer users towards having Signed-By for each
source such that we can retire a shared keyring across sources
which improves resilience against configuration issues and
incompetent malicious actors.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Provide snapshot support for offical Debian and Ubuntu archives.
There are two ways to enable snapshots for sources:
1. Add Snapshot: yes to your sources file ([snapshot=yes]). This
will allow you to specify a snapshot to use when updating or
installing using the --snapshot,-S option.
2. Add Snapshot: ID to your sources files to request a specific
snapshot for this source.
Snapshots are discovered using Label and Origin fields in the Release
file of the main source, hence you need to have updated the source at
least once before you can use snapshots.
The Release file may also declare a snapshots server to use, similar
to Changelogs, it can contain a Snapshots field with the values:
1. `Snapshots: https://example.com/@SNAPSHOTID@` where `@SNAPSHOTID@`
is a placeholder that is replaced with the requested snapshot id
2. `Snapshots: no` to disable snapshot support for this source.
Requesting snapshots for this source will result in a failure
to load the source.
The implementation adds a SHADOWED option to deb source entries,
and marks the main entry as SHADOWED when a snapshot has been
requested, which will cause it to be updated, but not included
in the generated cache.
The concern here was that we need to keep generating the shadowed
entries because the cleanup in `apt update` deletes any files not
queued for download, so we gotta keep downloading the main source.
This design is not entirely optimal, but avoids the pitfalls of
having to reimplement list cleanup.
Gaps:
- Ubuntu Pro repositories and PPAs are not yet supported.
|
| |/
|
|
|
| |
This runs update before opening the cache and sources.list for
installing/upgrading.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In an ideal world everyone would read release notes, but if the last
sources.list change is any indication a lot of people wont. This is
even more a problem in so far as apt isn't producing errors for
invalid repositories, but instead carries on as normal even through it
will not be able to install upgrades for the moved packages.
This commit implements two scenarios and prints a notice in those cases
pointing to the release notes:
a) User has 'non-free' but not 'non-free-firmware'
b) User has a firmware package which isn't available from anywhere
Both only happen if we are talking about a repository which identifies
itself as one of Debian and is for a release codenamed bookworm (or
sid). Note that as (usually) apt/oldstable is used to upgrade to the
new stable release these suggestions only show for users after they
have upgraded to bookworm on apt command line usage after that.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The command line is evaluated in two steps: First all packages given
are marked for install and as a second step the resolver is started on
all of them in turn to get their dependencies installed.
This is done so a user can provide a non-default choice on the command
line and have it respected regardless of where on the command line it
appears.
On the other hand, the order in which dependencies are resolved can
matter, so instead of using a "random" order, we now do this in the
order given on the command line, so if you e.g. have a meta package
pulling in non-default choices and mention it first the choices are
respected predictably instead of depending on first appearance of the
package name while creating the binary cache.
I might have "broken" this more than a decade ago while introducing the
reworked command line parsing for Multi-Arch, which also brought in the
split into the two steps mentioned above which was the far more
impactful 'respect user choice' change. This one should hardly matter in
practice, but as the tests show, order can have surprising side effects.
|
| |
|
|
|
| |
Reported-By: gcc
Gbp-Dch: Ignore
|
| |
|
|
|
|
|
|
| |
Support for envvar NO_COLOR was added in 2.3.11, but with our own
options we can also be a tiny bit more sensible in not overriding
an explicit choice to disable colors.
References: 400a6895566b67d70bcde43dc8a1cc1c7121f87d
|
| |
|
|
|
|
| |
Because the auto installer now also marks other binaries in the
package for upgrade, we do need to run it or we don't mark those
for upgrade.
|
| |
|
|
|
|
|
| |
Some of our headers use APT_COMPILING_APT trickery to avoid exposing too
broadly details we don't want external clients to know and make use of.
The flip-side is that this can lead to different compilation units
seeing different definitions if they aren't all using the same config.
|
| |
|
|
|
|
|
|
| |
Our public interface doesn't use zlib for quite a while now so lets drop
the last remnants as hopefully nobody depends on us bringing it in…
Unlike our own private lib for transitive provision of unistd.h.
References: 680b916ce7203a40ebd0a3882b9a71ca77278a67
|
| |\
| |
| |
| |
| | |
Do not accept arguments for apt-cache dotty, xvcg
See merge request apt-team/apt!237
|
| | |
| |
| |
| |
| |
| |
| | |
These commands do not actually interpret the same
arguments as depends, or any own ones for that matter.
Gbp-Dch: full
|
| |\ \
| |/
|/|
| |
| | |
Consistently dealing with fields via pkgTagSection::Key
See merge request apt-team/apt!233
|
| | |
| |
| |
| |
| |
| |
| | |
We abstract hashes a fair bit to be able to add new ones eventually,
which lead us to building the field names on the fly. We can do better
through by keeping a central place for these names, too, which even
helps in reducing code as we don't need the MD5 → Files dance anymore.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The speed critical paths were converted earlier, but the remaining
could benefit a tiny bit from this as well especially as we have the
facility now available and can therefore brush up the code in various
places in the process as well.
Also takes the time to add the hidden Exists method advertised in
the headers, but previously not implemented.
|
| |/
|
|
|
|
|
|
| |
We forgot to check whether Archive() and Codename() exist in
the first place, sigh. Maybe we should return empty strings
instead of nullptr.
Reported-By: Johannes 'josch' Schauer Marin Rodrigues on IRC
|
| |
|
|
|
|
|
|
|
| |
Our EDSP code is confused by the spaces in the package name, so we adopt
a naming scheme similar to build-dep here instead of trying to teach
EDSP to somehow encode the spaces as that is probably even more
confusing for onlookers than this invalid package name is.
Reported-By: Johannes Schauer Marin Rodrigues on IRC
|
| |
|
|
|
| |
This adds back the missing fields that we do not show any
other way.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Debian 11 release notes elevate matching with regex to a documented
and much used feature, which it previously wasn't. For binary packages
this is not a problem, but source packages are special and it turns out
that matching by release is here an exact string match only.
A bit of refactoring later we can reuse the code we use for Packages
files also for Release files, which is what we have for Sources files as
those files itself have no representation in the cache.
This means that we do not support matching based on components (c=main)
in source, but we didn't before and we can cross that bridge if anyone
notices…
Closes: #998444
|
| |
|
|
| |
Let's make this one step harder.
|
| |\
| |
| |
| |
| | |
Allow =version and /release selectors on virtual packages
See merge request apt-team/apt!121
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We already have code for figuring out if a virtual package is only
provided by a single provider (and otherwise show a list) we can
auto-select for the user, so we can adapt that to work with versioned
provides as well and while at it also release selectors.
The code tries to keep ABI backward compatible and hence turns
relatively ugly as we need a parameter (the selector) to be passed
around without adding a parameter or new virtual methods.
|
| | |
| |
| |
| |
| | |
When color has not been turned on explictly in the configuration
file or options, only turn it on if NO_COLOR is not set.
|
| |\ \
| | |
| | |
| | |
| | | |
Streamline access to barbarian architecture functionality
See merge request apt-team/apt!184
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
APT is not the place this information should be stored at, but it is a
good place to experiment and see what will be (not) needed in the future
for a proper implementation higher up the stack.
This is why "BarbarianArchitectures" is chosen instead of a more neutral
and/or sensible "VeryForeign" and isn't readily exported in the API to
other clients for this PoC as a to be drawn up standard will likely
require potentially incompatible changes. Having a then outdated and
slightly different implementation block a "good" name would be bad.
The functionality itself mostly exists (ignoring bugs) since the
introduction of MultiArch as we always had the risk of encountering
packages of architectures not known to dpkg (forced onto the system,
potentially before MultiArch) we had to deal with somehow and other
edge cases.
All this commit really does is allowing what could previously only be
achieved with editing sources.list and some conf options via a single
config option: -o APT::BarbarianArchitectures=foo,bar
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Back than M-A was added to build-dependencies (#558104) only the
qualifiers :native and :any were considered at first which for the
native case behave the same, so stripping was a good idea.
Nowadays we could encounter arch-qualified dependencies, too, through –
or slightly more likely conflicts perhaps – at least in theory as in
practice native build-dep operations in Debian and elsewhere wouldn't
have other architectures available anyhow.
Still, we have full support for all this for the crossbuilding case
which makes active use of this (at least is far more likely to do so),
so it seems better to converge on one edgecase rather than keeping
two in active use and so produce potentially different results for not
specifying -a and -a $native.
|
| |/ /
| |
| |
| |
| |
| |
| | |
As we never display the information in these code paths there isn't a
lot of point in calculating it first saving us some precious CPU cycles.
References: d6f3458badf2cfea3ca7de7632ae31daff5742be
|
| | |
| |
| |
| |
| | |
Comparison operators need to be const-invocable now, but
otherwise no change seems necessary.
|
| | |
| |
| |
| |
| |
| |
| | |
We just used the pointer returned which might be nullptr, properly
call BuildSourceList() and check the result first.
Closes: #990518
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If a source is not copying files to the destination the download code
forces the copy – which in practice are local repositories accessed
via file:/ – but in that process takes the filename the local repo used
rather than the filename it e.g. advertised via --print-uris.
A local repository could hence override a file in the current directory
if you use 'apt download', which is a rather weak ability, but still.
|
| | |
| |
| |
| | |
This reverts commit 64127478630b676838735b509fec5cdfa36874c8.
|
| |\ \
| | |
| | |
| | |
| | | |
Count uninstallable packages in "not upgraded"
See merge request apt-team/apt!169
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If a first step of the solver can figure out that a package is
uninstallable it might reset the candidate so that later steps are
prevented from exploring this dead end. While that helps the resolver it
can confuse the display of the found solution as this will include an
incorrect count of packages not upgraded in this solution.
It was possible before, but happens a fair bit more with the April/May
resolver changes last year so finally doing proper counting is a good
idea.
Sadly this is a bit harder than just getting the number first and than
subtracting the packages we upgraded from it as the user can influence
candidates via the command line and a package which could be upgraded,
but is removed instead shouldn't count as not upgraded as we clearly did
something with it. So we keep a list of packages instead of a number
which also help in the upgrade cmds as those want to show the list.
Closes: #981535
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
An interactive tool like aptitude needs these flags current far more
often than we do as a user can see them in apt only in one very well
defined place – the autoremove display block – so we don't need to run
it up to four times while a normal "apt install" is processed as that is
just busywork.
The effect on runtime is minimal, as a single run doesn't take too long
anyhow, but it cuts down tremendously on debug output at the expense of
requiring some manual handholding.
This is opt-in so that aptitude doesn't need to change nor do we need to
change our own tools like "apt list" where it is working correctly as
intended.
A special flag and co is needed as we want to prevent the ActionGroup
inside pkgDepCache::Init to be inhibited already so we need to insert
ourselves while the DepCache is still in the process of being built.
This is also the reason why the debug output in some tests changed to
all unmarked, but that is fine as the marking could have been already
obsoleted by the actions taken, just inhibited by a proper action group.
|
| | |
| |
| |
| |
| |
| | |
The code missed a break, so it was looping infinitely because
the while loop condition only checked for '\n' and '\r', but not
end of file.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Hook protocol 0.2 makes the new fields we added mandatory, and
replaces `install` mode with `upgrade`, `downgrade`, `reinstall`
where appropriate.
Hook negotiation is hacky, but it's the best we can do for now.
Users are advised to upgrade to 0.2
|
| | |
| |
| |
| | |
This enables hooks to output additional information.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
Provide access to the origins of a package, such that tools
can display information about them; for example, you can write
a hook counting security upgrades.
|
| | |
| |
| |
| | |
This ensures messages are displayed in the correct order.
|
| | |
| |
| |
| | |
This is the only nullable thing we have here.
|