Do not crash in 'apt show' for non-installed packages
For a non-installed package, manual_installed was set to the null
pointer. This was passed to Tag::Rewrite, which expects an string
(empty for null-type values) and the conversion from null pointer
to string does not work correctly.
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.
projects / apt.git / log
