Drop the Section field from pkgCache::Package again
This somehow got back, we don't really know why. Emulate the
Section() method in the PkgIterator by looking at the section
of the head of the VersionList.
Tomas Pospisek [Tue, 27 Jan 2015 13:10:38 +0000 (14:10 +0100)]
document APT::Periodic::RandomSleep
The documentation in the patch is from
https://help.ubuntu.com/community/AutomaticSecurityUpdates
That page is licensed under Creative Commons Attribution-ShareAlike
3.0. Because I'm unsure how that license meshes with apt's license
I've not copied the text but formulated the same information freely
in my own words.
The original text was contributed by Chris Bainbridge [1][3]
and Kees Cook [2]. Thanks to them.
Daniel Hartwig [Tue, 11 Aug 2015 17:56:31 +0000 (19:56 +0200)]
replace direct calls to egrep with grep -E
The rest of the initial patch is not needed or incorrect in our usage.
Big changes for the dselect scripts seem unneeded as well as those are
hardly used by anyone anymore…
[commit message written by commiter]
Closes: 255577
Thanks: David Weinehall for initial patch
apt-pkg/sourcelist.cc: In destructor ‘pkgSourceList::~pkgSourceList()’:
apt-pkg/sourcelist.cc:278:4: warning: cannot optimize loop, the loop counter may overflow [-Wunsafe-loop-optimizations]
for (pkgIndexFile * const File : VolatileFiles)
^
There really cannot be an overflow, though. Rewriting it like this
seems to fix it.
move manual-bit from 'oldlibs' pkg to its dependencies
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.
move APT::Never-MarkAuto-Sections handling to MarkDelete
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.
change to libapt-pkg abi 5.0 with versioned symbols
We changed an aweful lot of stuff, so 5.0 is properly better than 4.X as
a semantic version and as we are at it lets add some trivial symbol
versioning as well: We just mark all exported symbols with the same
version for now. This isn't really the proper thing to do as if we add
symbols in later versions (with the same abi) they will get the same
symbols version, but our .symbols file will protect us from the problems
arising from this as it will ensure that a package acutally depends on a
version of the abi high enough to include the symbol.
cxx11abi transition happens, we changed a bunch of methods and all that
stuff which is really good™ for an abi. Lets just slowly start to stop
changing more and a first step is to document the current so changes
aren't hidding in a big wall of change anymore.
mark again deps of pkgs in APT::Never-MarkAuto-Sections as manual
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
drop extra newline in 'Failed to fetch' and 'GPG error' message
I never understood why there is an extra newline in those messages, so
now is as good time as any to drop them. Lets see if someone complains
with a good reason to keep it…
enhance "hit paywall" error message to mention the probable cause
Reporting errors from Done() is bad for progress reporting and such, so
factoring this out is a good idea and we start with moving the supposed-
to-be clearsigned file isn't clearsigned out first – improving the error
message in the process as we use the same message for a similar case
(NODATA) as this is what I have to look at with the venue wifi at
DebCamp and the old errormessage doesn't really say anything.
parse packages from all architectures into the cache
Now that we can dynamically create dependencies and provides as needed
rather than requiring to know with which architectures we will deal
before running we can allow the listparser to parse all records rather
than skipping records of "unknown" architectures.
This can e.g. happen if a user has foreign architecture packages in his
status file without dpkg knowing about this architecture (or apt
configured in this way).
A sideeffect is that now arch:all packages are (correctly) recorded as
available from any Packages file, not just from the native one – which
has its downsides for the resolver as mixed-arch source packages can
appear in different architectures at different times, but that is the
problem of the resolver and dealing with it in the parser is at best a
hack (and also depends on a helpful repository).
Another sideeffect is that his allows :none packages to appear in
Packages files again as we don't do any kind of checks now, but given
that they aren't really supported (anymore) by anyone we can live with
that.
eliminate dead file-provides code in cache generation
The code was never active in production, it just sits there collecting
dust and given that it is never tested probably doesn't even work
anymore the way it was supposed to be (whatever that was exactly in the
first place). So just remove it before I have to "fix" it again next
time.
elimate duplicated code in pkgIndexFile subclasses
Trade deduplication of code for a bunch of new virtuals, so it is
actually visible how the different indexes behave cleaning up the
interface at large in the process.
Sources are usually defined in sources.list (and co) and are pretty
stable, but once in a while a frontend might want to add an additional
"source" like a local .deb file to install this package (No support for
'real' sources being added this way as this is a multistep process).
We had a hack in place to allow apt-get and apt to pull this of for a
short while now, but other frontends are either left in the cold by this
and/or the code for it looks dirty with FIXMEs plastering it and has on
top of this also some problems (like including these 'volatile' sources
in the srcpkgcache.bin file).
So the biggest part in this commit is actually the rewrite of the cache
generation as it is now potentially a three step process. The biggest
problem with adding support now through is that this makes a bunch of
previously mostly unusable by externs and therefore hidden classes
public, so a bit of further tuneing on this now public API is in order…
just-in-time creation for (explicit) negative deps
Now that we deal with provides in a more dynamic fashion the last
remaining problem is explicit dependencies like 'Conflicts: foo' which
have to apply to all architectures, but creating them all at the same
time requires us to know all architectures ending up in the cache which
isn't needed to be the same set as all foreign architectures.
The effect is visible already now through as this prevents the creation
of a bunch of virtual packages for arch:all packages and as such also
many dependencies, just not very visible if you don't look at the stats…
Expecting the worst is easy to code, but has its disadvantages e.g.
by creating package structures which otherwise would have never
existed. By creating the provides instead at the time a package
structure is added we are well prepared for the introduction of partial
architectures, massive amounts of M-A:foreign (and :allowed) and co as
far as provides are concerned at least. We have something relatively
similar for dependencies already.
Many tests are added for both M-A states and the code cleaned to
properly support implicit provides for foreign architectures and
architectures we 'just' happen to parse.
Before MultiArch implicits weren't a thing, so they were hidden by
default by definition. Adding them for MultiArch solved many problems,
but having no reliable way of detecting which dependency (and provides)
is implicit or not causes problems everytime we want to output
dependencies without confusing our observers with unneeded
implementation details.
The really notworthy point here is actually that we keep now a better
record of how a dependency came to be so that we can later reason about
it more easily, but that is hidden so deep down in the library internals
that change is more the problems it solves than the change itself.
We store very few flags in the cache, so keeping storage space for 8 is
enough for all of them and still leaves a few unused bits remaining for
future extensions without wasting bytes for nothing.
We aren't and we will not be really compatible again with the previous
stable abi, so lets drop these markers (which never made it into a
released version) for good as they have outlived their intend already.
Cache generation needs a way of quickly iterating over the unique potion
of the dependencies to be able to share them. By linking them together
we can reduce the speed penality (~ 80%) with only a small reduction in
saved size (~ 20%).
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.
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.
With a bit of trickery and the Curiously recurring template pattern we
can free us from our use of virtual in the iterators were it is unneeded
bloat as we never deal with pointers to iterators and similar such.
show or-groups in not-installed recommends and suggests lists
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.
Housekeeping. This used to be embedded in apt-get directly, then moved
to into our (then new) private lib and now header and code get a proper
separation.
apt-get is displaying various lists of package names, which until now it
was building as a string before passing it to ShowList, which inserted
linebreaks at fitting points and showed a title if needed, but it never
really understood what it was working with. With the help of C++11 the
new generic knows not only what it works with, but generates the list on
the fly rather than asking for it and potentially discarding parts of
the input (= the non-default verbose display). It also doubles as a test
for how usable the CacheSets are with C++11.
The library(s) make an API break anyhow, so lets ensure we use gcc5 for
this break and enable c++11 as standard as gcc6 will use it as default
and should provide some API parts for c++11 – beside that it can't hurt
to use c++11 itself. We just have to keep our headers c++03 compatible
to not enforce a standrd bump in our reverse dependencies.
'files' is a bit too generic as a name for a command usually only used
programmatically (if at all) by developers, so instead of "wasting" this
generic name for this we use "indextargets" which is actually the name
of the datastructure the displayed data is stored in.
Along with this rename the config options are renamed accordingly.
Helmut Grohne rightly suggests on IRC now that there isn't much point in
getting the locks for root either as the output isn't in any way more
authoritive than without locking given that after this call the lock is
freed and any action can sneak in before we make the next call. So we
exchange no benefit for the disavantage of blocking real calls. This can
be especially confusing with the aliases --no-act and --just-print.
We do not print the message we print for users through as the non-root
users can be confronted with a lot more difference via unreadable files.
Redirectors like httpredir.debian.org orchestra the download from
multiple (hopefully close) mirrors while having only a single central
sources.list entry by using redirects. This has the effect that the
progress report always shows the source it started with, not the mirror
it ends up fetching from, which is especially problematic for error
reporting as having a report for a "Hashsum mismatch" for the redirector
URI is next to useless as nobody knows which URI it was really fetched
from (regardless of it coming from a user or via the report script) from
this output alone. You would need to enable debug output and hope for
the same situation to arise again…
We hence reuse the UsedMirror field of the mirror:// method and detect
redirects which change the site and declare this new site as the
UsedMirrror (and adapt the description).
The disadvantage is that there is no obvious mapping anymore (it is
relatively easy to guess through with some experience) from progress
lines to sources.list lines, so error messages need to take care to use
the Target description (rather than current Item description) if they
want to refer to the sources.list entry.
skip .diff/Index acquire if Release file was a hit
QuereURI already skips the aquire of the real file in such a case, but
it can't detect pdiffs this way. Those already have a handling if the
file wasn't changed in between two Release files, so we just add an
other check for a Release file hit here, too.
C++11 adds the 'override' specifier to mark that a method is overriding
a base class method and error out if not. We hide it in the APT_OVERRIDE
macro to ensure that we keep compiling in pre-c++11 standards.
By further abstracting the iterator templates we can wrap the reverse
iterators of the wrapped containers and share code in a way that
iterator creating is now more template intensive, but shorter in code.
The "problem" is mostly in the erase() definitions as they slightly
conflict and in pre-c++11 are not uniformly in different containers.
By differenciating based on the standard we can provide erase() methods
for both standards – and as the method is in a template and inline we
don't need to worry about symbols here.
The rest is adding wrappings for the new forward_list and unordered_set
containers and correcting our iterators to use the same trait as the
iterator they are wrapping instead of having all of them be simple
forward iterators. This allows the use of specialized algorithms which
are picked based on iterator_traits and implementing them all is simple
to do as we can declare all methods easily and only if they are called
they will generate errors (if the underlying iterator doesn't support
these).
implement Signed-By without using gpg for verification
The previous commit returns to the possibility of using just gpgv for
verification proposes. There is one problem through: We can't enforce a
specific keyid without using gpg, but our acquire method can as it
parses gpgv output anyway, so it can deal with good signatures from not
expected signatures and treats them as unknown keys instead.
If all keyrings are simple keyrings we can merge the keyrings with cat
rather than doing a detour over gpg --export | --import (see #790665),
which means 'apt-key verify' can do without gpg and just use gpgv as
before the merging change.
We declare this gpgv usage explicit now in the dependencies. This isn't
a new dependency as gnupg as well as debian-archive-keyring depend on
and we used it before unconditionally, just that we didn't declare it.
The handling of the merged keyring needs to be slightly different as our
merged keyring can end up containing the same key multiple times, but at
least currently gpg does remove only the first occurrence with
--delete-keys, so we move the handling to a if one is gone, all are gone
rather than an (implicit) quid pro quo or even no effect.
The output of gpg slightly changes in 2.1 which breaks the testcase, but
the real problem is that this branch introduces a new default keyring
format (which is called keybox) and mixing it with simple keyrings (the
previous default format) has various problems like failing in the keybox
to keyring import (#790665) or [older] gpgv versions not being able to
deal with keyboxes (and newer versions as well currently:
https://bugs.gnupg.org/gnupg/issue2025).
We fix this by being a bit more careful in who creates keyrings (aka: we
do it or we take a simple keyring as base) to ensure we always have a
keyring instead of a keybox. This way we can ensure that any version
combination of gpv/gpgv2 and gnupg/gnupg2 without doing explicit version
checks and use the same code for all of them.
It is sometimes handy to know how apt-key exactly called gpg, so adding
a pair of options to be able to see this if wanted is added. Two are
needed as some commands output is redirected to /dev/null, while sfor
others stdout is piped into another gpg call so in both cases you
wouldn't see all and hence you can choose.
There is an option to keep all targets (Packages, Sources, …) compressed
for a while now, but the all-or-nothing approach is a bit limited for
our purposes with additional targets as some of them are very big
(Contents) and rarely used in comparison, so keeping them compressed by
default can make sense, while others are still unpacked.
Most interesting is the copy-change maybe: Copy is used by the acquire
system as an uncompressor and it is hence expected that it returns the
hashes for the "output", not the input. Now, in the case of keeping a
file compressed, the output is never written to disk, but generated in
memory and we should still validated it, so for compressed files copy is
expected to return the hashes of the uncompressed file. We used to use
the config option to enable on-the-fly decompress in the method, but in
reality copy is never used in a way where it shouldn't decompress a
compressed file to get its hashes, so we can save us the trouble of
sending this information to the method and just do it always.
remove the longtime deprecated vendor{,list} stuff
History suggests that this comes from an earlier apt-secure
implementation, but never really became a thing, totally unused and
marked as deprecated for "ages" now. Especially as it did nothing even
if it would have been used (libapt itself didn't use it at all).
Limits which key(s) can be used to sign a repository. Not immensely useful
from a security perspective all by itself, but if the user has
additional measures in place to confine a repository (like pinning) an
attacker who gets the key for such a repository is limited to its
potential and can't use the key to sign its attacks for an other (maybe
less limited) repository… (yes, this is as weak as it sounds, but having
the capability might come in handy for implementing other stuff later).
add sources.list Check-Valid-Until and Valid-Until-{Max,Min} options
These options could be set via configuration before, but the connection
to the actual sources is so strong that they should really be set in the
sources.list instead – especially as this can be done a lot more
specific rather than e.g. disabling Valid-Until for all sources at once.
Valid-Until-* names are chosen instead of the Min/Max-ValidTime as this
seems like a better name and their use in the wild is probably low
enough that this isn't going to confuse anyone if we have to names for
the same thing in different areas.
In the longrun, the config options should be removed, but for now
documentation hinting at the new options is good enough as these are the
kind of options you set once across many systems with different apt
versions, so the new way should work everywhere first before we
deprecate the old way.
indexRecords was used to parse the Release file – mostly the hashes –
while metaIndex deals with downloading the Release file, storing all
indexes coming from this release and … parsing the Release file, but
this time mostly for the other fields.
That wasn't a problem in metaIndex as this was done in the type specific
subclass, but indexRecords while allowing to override the parsing method
did expect by default a specific format.
APT isn't really supporting different types at the moment, but this is
a violation of the abstraction we have everywhere else and, which is the
actual reason for this merge: Options e.g. coming from the sources.list
come to metaIndex naturally, which needs to wrap them up and bring them
into indexRecords, so the acquire system is told about it as they don't
get to see the metaIndex, but they don't really belong in indexRecords
as this is just for storing data loaded from the Release file… the
result is a complete mess.
I am not saying it is a lot prettier after the merge, but at least
adding new options is now slightly easier and there is just one place
responsible for parsing the Release file. That can't hurt.
projects / apt.git / log
