| Age | Commit message (Collapse) | Author |
|---|
|
|
|
People should know that this is exists.
|
|
This release is made for Niels Thykier and apt-file.
|
|
|
|
|
|
Git-Dch: Ignore
|
|
|
|
Closes: 807413
|
|
|
|
This should make it more obvious that CHANGEPATH is a placeholder which
apt will replace with a package specific path rather than a string
constant.
Mail-Reference: <87d1upgvaf.fsf@deep-thought.43-1.org>
Mail-Archive: https://lists.debian.org/debian-dak/2015/12/msg00005.html
|
|
Git-dch: ignore
|
|
|
|
|
|
|
|
Git-Dch: ignore
|
|
debian/experimental
|
|
Git-Dch: Ignore
|
|
|
|
Never updating this information is wrong, updating it automatically
isn't super correct either, but it seems conventional to have it and
updating it more often than needed seems better than updating it never.
Git-Dch: Ignore
|
|
In 12f7536 I chose to opt for a slightly better text which avoids
assigning copyright to the FSF (not because it would be wrong to do it,
but is usually not what the contributor intended, but just the default.
xgettext has a --foreign flag for avoiding the copyright, but po4a
hasn't and an empty copyright-holder doesn't work either, so this little
rework of files with sed and cat.
Git-Dch: Ignore
|
|
The manpages were fixed by Justin B Rye, lets deal with the rest now.
Git-Dch: Ignore
|
|
|
|
|
|
|
|
|
|
Reference mail:
https://lists.debian.org/debian-l10n-english/2015/11/msg00006.html
|
|
Reported-By: codespell
Git-Dch: Ignore
|
|
Git-Dch: Ignore
|
|
Closes: 805474
|
|
Based on a discussion with Niels Thykier who asked for Contents-all this
implements apt trying for all architecture dependent files to get a file
for the architecture all, which is treated internally now as an official
architecture which is always around (like native). This way arch:all
data can be shared instead of duplicated for each architecture requiring
the user to download the same information again and again.
There is one problem however: In Debian there is already a binary-all/
Packages file, but the binary-any files still include arch:all packages,
so that downloading this file now would be a waste of time, bandwidth
and diskspace. We therefore need a way to decide if it makes sense to
download the all file for Packages in Debian or not. The obvious answer
would be a special flag in the Release file indicating this, which would
need to default to 'no' and every reasonable repository would override
it to 'yes' in a few years time, but the flag would be there "forever".
Looking closer at a Release file we see the field "Architectures", which
doesn't include 'all' at the moment. With the idea outlined above that
'all' is a "proper" architecture now, we interpret this field as being
authoritative in declaring which architectures are supported by this
repository. If it says 'all', apt will try to get all, if not it will be
skipped. This gives us another interesting feature: If I configure a
source to download armel and mips, but it declares it supports only
armel apt will now print a notice saying as much. Previously this was a
very cryptic failure. If on the other hand the repository supports mips,
too, but for some reason doesn't ship mips packages at the moment, this
'missing' file is silently ignored (= that is the same as the repository
including an empty file).
The Architectures field isn't mandatory through, so if it isn't there,
we assume that every architecture is supported by this repository, which
skips the arch:all if not listed in the release file.
|
|
The general idea is: A small paragraph on the tool itself as a
description, a list of the most used (!= all) commands available in the
tool, a remark where to find more information on the tool and its
commands (aka: in the manpage) and finally a common block referring to
even more manpages. In exchange options are completely omitted from the
output as well as deprecated or obscure commands. (Better) Information
about them is available in the manpages anyway and the few options which
were listed before were also the least interesting ones (-o -c -q and co
are hardly of interest for someone totally new looking to find info by
asking for help and anyone with a bit of experience doesn't need this
short list. Those would need a list of options applying to the command
they call, but they are too numerous and command specific to list them
sanely in this context.
|
|
That is one huge commit with busy work only: Help messages used to be
one big translateable string, which is a pain for translators and hard
to reuse for us. This change there 'explodes' this single string into
new string for each documented string trying hard to split up the
translated messages as well. This actually restores many translations as
previously adding a single command made all of the bug message fuzzy.
The splitup also highlighted that its easy to forget a line, duplicate
one and similar stuff.
Git-Dch: Ignore
|
|
As apt is targetted at users, lets try to make apt(8) for users as well
by giving only a quick overview about what is available and some
pointers for how to find a whole lot more details.
|
|
Especially with apt now, it can be useful to set an option only for apt
and not for apt-get. Using a binary-specific subtree which is merged into
the root seems like a simple enough trick to achieve this.
|
|
The manpage is also slightly updated to work better as a central hub to
push people from all angles into the right directions without writting a
book disguised as an error message.
|
|
In b0d408547734100bf86781615f546487ecf390d9 I accidently removed the
documentation for Trusted and replaced it with Signed-By instead of
adding it.
Git-Dch: Ignore
|
|
As we have support for 'hold', we need support for undoing a hold which
in effect means that we implemented most other states as well, just that
they weren't exposed in the interface directly so far.
|
|
|
|
Git-dch: ignore
|
|
This avoids churn in the po/pot files when just the location line
number in the source code changes.
Git-Dch: ignore
|
|
This changes the semantics of the option (which is renamed too) to be a
yes/no value with the special additional value "force" as this allows
by-hash to be disabled even if the repository indicates it would be
supported and is more in line with our other yes/no options like pdiff
which disable themselves if no support can be detected.
The feature wasn't documented so far and hasn't reached a (un)stable
release yet, so changing it without trying too hard to keep
compatibility seems okay.
|
|
|
|
The syntax of "Source" is different in EDSP compared to the the field of
the same name in 'the rest' of Debian, so documented this accordingly
and send the version as a new field.
|
|
Git-Dch: ignore
|
|
|
|
Git-Dch: Ignore
|
|
|
|
Some targets like Contents-udeb are special-needs targets. Shipping the
configuration snippet for them is okay, but they shouldn't be downloaded
by default. Forcing the user to enable targets by uncommenting targets
is wrong and this would still not really solve the problem completely as
even if you want to download some -udebs it will probably not be for all
sources you have enabled, so having the possibility of disabling a
target by default, but giving the user the option to enable it on a
per-source entry basis is better.
|
|
Some additional files like 'Contents' are very big and should therefore
kept compressed on the disk, which apt-file did in the past. It also
implemented pdiff patching of these files by un- and recompressing these
files on-the-fly, with this commit we can do the same – but we can do
this in both pdiff patching styles (client and server merging) and
secured by hashes.
Hashes are in so far slightly complicated as we can't compare the hashes
of the compressed files as we might compress them differently than the
server would (different compressor versions, options, …), so we must
compare the hashes of the uncompressed content.
While this commit has changes in public headers, the classes it changes
are marked as hidden, so nobody can use them directly, which means the
ABI break is internal only.
|
|
This updates the documentation for a change which actually happened in
c2a4a8dded2dfb56dbcab9689b6cb4b96c9999b6 already. The acquire system
expects the $(SITE) to be there (e.g. for mirror rewriting) so we are
better of prefixing it automatically than giving frontends the chance to
forget it. There is no point in not showing $(SITE) first anyway.
|
