Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
|
|
|
|
This makes it consistent with the general dpkg behaviour of honouring
file removals by the administrator.
Closes: #550252
As a side effect, this avoids useless errors when the destination
directory is not existent or writable.
Closes: #581544
|
|
The option forces a conffile prompt when the conffile from the new
package does not differ from the previous one version.
Closes: #102609
Signed-off-by: Guillem Jover <guillem@debian.org>
|
|
Detect when another process has locked the database, and mention that
problematic dpkg --audit results might be due to ongoing operations.
Closes: #80252
|
|
|
|
Use next/prev instead of next/back (which would complement forward).
Also move next to the end of member names and seprate it with an
underscore, to simulate it being a sub struct member.
|
|
|
|
This avoids a global exit code variable.
|
|
|
|
The two struct pkginfoperfile inside struct pkginfo are always valid,
as blankpackage does a blankpackageperfile on each. So there's no
actual need for the boolean member, neither for validity checks all
over the place and possible subsequent redundant initializations.
This is due to commit 5f100a01af636c14a600bf53b22e2ca3f2fcc546.
|
|
|
|
debug() already prints a trailing newline, so there's no point in
including it in the string to be printed.
|
|
|
|
|
|
|
|
Coallesce the ellipsed string with the format string so that it makes a
bit more sense for translators. This will allow translators to use for
example the UTF-8 ellipsis character.
|
|
|
|
Move the return point in tarobject() for the existing directories
check after the path filter one. This makes sure the latter takes
precedence over the former, and existing directories get properly
filtered and removed on upgrades.
Reported-by: Martin Pitt <martin.pitt@ubuntu.com>
Signed-off-by: Guillem Jover <guillem@debian.org>
|
|
Because the filtered file is left in the new file list, the code that
verifies if the old file is present (maybe with a different name) in
the new list matches the stat information. So we mark and treat filtered
files as if they were already not present on the file system.
Reported-by: Martin Pitt <martin.pitt@ubuntu.com>
Signed-off-by: Guillem Jover <guillem@debian.org>
|
|
This provides support for filtering paths on package installation. This
allows embedded systems to skip /usr/share/doc, manpages, etc.
dpkg does not lose track of excluded paths during filtering, and they
get checked for file conflicts as usual, so filters are not a way to
avoid file conflict situations.
Closes: #68788, #68861, #497304, #525567, #583902
Based-on-patch-by: Tollef Fog Heen <tfheen@err.no>
Signed-off-by: Martin Pitt <martin.pitt@ubuntu.com>
Signed-off-by: Guillem Jover <guillem@debian.org>
|
|
|
|
This detangles the two independent actions, removing from the list and
skiping the file from the tarball.
|
|
|
|
|
|
|
|
Due to the performance degradation on ext4 file systems, as a
workaround on Linux, we use sync() which is synchronous, before
rename() to make sure it's truly atomic.
Closes: #578635
|
|
The cmd->filename variable was getting the full path to the maintainer
script inside the chroot, and once dpkg had changed root, the path was
not valid anymore.
Regression introduced in 5050748f1a6bb0c0728f8c07f9058d545c80d7e0.
Closes: #580984
|
|
This happens when the we install first the replacing then the replaced
package, for which the replaced package is supposed to get disappeared.
And fixes it to disappear the correct package and not lose track of the
ownership of the replaced files, by marking the replaced file as not
being part of the unpacked archive.
|
|
Change does_replace() to take an additional argument for the old
‘struct pkginfoperfile’, instead of hardcoding oldpigp->installed.
Which we use by passing pkg->available when checking if the current
package has files replaced by files from an already installed package.
Closes: #568566
|
|
It can be used to find out the location of some internal dpkg programs
that might be called from maintainer scripts. That way we can avoid
hardcoding /usr/lib/dpkg and maintainer scripts will still work when
called from a dpkg manually installed in /usr/local for example.
|
|
The idea is that specialized hooks can benefit from this information to
do the right thing. The same call would be put in the various maintainer
scripts but the actions taken would be different depending on the script
nevertheless.
|
|
When creating hard links on extraction use the .dpkg-new filename
for source as the normal file is not yet in place due to the rename
deferral.
We avoid doing this for hard links to special files (which do not
have the fnnf_deferred_rename flag) because they are already in
place. Although this should not always pose a problem because not
all tar creation implementations support hard links for non-normal
files, but at least FreeBSD libarchive based ones support them for
fifos, so better be safe than sorry.
Based-on-patch-by: Colin Watson <cjwatson@ubuntu.com>
|
|
Report these errors directly through status-fd, instead of reporting
later on errors which are a consequence of those first errors, which
can be pretty confusing for a front-end.
Closes: #574599
Signed-off-by: Guillem Jover <guillem@debian.org>
|
|
|
|
Split packages() into bite-sized pieces. No functional change
intended.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Guillem Jover <guillem@debian.org>
|
|
It was scanning the old list of files so it would never install
new files.
|
|
Modern tar files typically use NormalFile1 rather than NormalFile0 for
file objects. A typo meant that the former never triggered rename
deferral.
|
|
dpkg's process_archive() was doing the improper assumption that a
readdir() loop would not return the same filename twice even when the
scanned directory has files renamed into it (coming from tmp.ci).
The net result of having the same filename returned twice is that the
the second time the updated file to install is no longer there and
thus dpkg removed the current metadata file believing that it was
obsolete. btrfs triggers this bug consistently.
All other readdir() occurrences have been reviewed as well for similar
problems. But they are all safe, they mainly unlink() files rather
than adding new files into the scanned directory.
Thanks to Carey Underwood and Chris Mason for their help in diagnosing
this problem.
Acked-by: Guillem Jover <guillem@debian.org>
|
|
This way it's done in one pass afterwards, to avoid massive I/O
degradation due to the serialization from each write + fsync. This
restores extraction times to numbers closer to the ones before the
fsync patch introduced in 1.15.6.
|
|
|
|
Remove bogus short options and use more appropriate act_ values for each
action.
|
|
|
|
|
|
After creating, renaming or unlinking database files sync its
containing directory, to guarantee the new file entry is correctly
listed in the directory.
Closes: #567089
Base-on-patch-by: Jean-Baptiste Lallement <jeanbaptiste.lallement@gmail.com>
|
|
The callers should not be concerned about where the package info
directory is located, the new functions encapsulates the knowdlegde
in the dbmodify module.
|
|
This removes almost duplicate strings for translation.
|
|
This guarantees the file contents will be there in case of abrupt
program termination (due to crashes for example, or user intervention).
This also guarantees the atomicity of rename(2) calls.
Closes: #430958
Based-on-patch-by: Jean-Baptiste Lallement <jeanbaptiste.lallement@gmail.com>
|