[SCM] dpkg's main repository branch, master, updated. 1.16.1.2-180-g4cde802
The following commit has been merged in the master branch:
commit 61b3201ddbd1fc5b8683309138d5482c95716f88
Author: Guillem Jover guil...@debian.org
Date: Tue Nov 15 21:59:17 2011 +0100
dpkg: Switch from foreign arch option to add and remove commands
The --foreign-architecture option is not a good interface, the problem
with it comes from the fact that the architectures supported by the
database are not configuration, they are state. This shows up in several
ways.
When a front-end needs to load the list of architectures, it needs to
get someone to parse dpkg.cfg files, this is currently done by dpkg
itself, and the list can be retrieved with --print-foreign-architectures,
the problem appears when wanting a front-end to load them through libdpkg.
Making the latter have to execute «dpkg --print-foreign-architectures»
would be suboptimal, and making libdpkg have to load dpkg.cfg would be
distasteful. Another issue is that if the list of foreign architectures
is on the configuration files it makes it slightly more tricky to
cross-grade dpkg, and it makes it fairly easy to accidentally remove
architectures required by the database.
Replace the option with two new commands --add-architecture and
--remove-architecture which will perform sanity checks and store and
load the architecture list (including the native arch) in an internal
db file under /var/lib/dpkg/.
diff --git a/lib/dpkg/dbmodify.c b/lib/dpkg/dbmodify.c
index 6981511..8922e46 100644
--- a/lib/dpkg/dbmodify.c
+++ b/lib/dpkg/dbmodify.c
@@ -276,6 +276,8 @@ modstatdb_open(enum modstatdb_rw readwritereq)
internerr(unknown modstatdb_rw '%d', readwritereq);
}
+ dpkg_arch_load_list();
+
if (cstatus != msdbrw_needsuperuserlockonly) {
cleanupdates();
if (cflags = msdbrw_available_readonly)
diff --git a/man/dpkg.1 b/man/dpkg.1
index a01ae42..390a478 100644
--- a/man/dpkg.1
+++ b/man/dpkg.1
@@ -231,6 +231,19 @@ deinstall any packages not in list given to
\-\-set\-selections.
Searches for packages selected for installation, but which for some
reason still haven't been installed.
.TP
+.B \-\-add\-architecture \fIarchitecture\fP
+Add \fIarchitecture\fP to the list of architectures for which packages can
+be installed without using \fB\-\-force\-architecture\fP. The architecture
+\fBdpkg\fP is built for (i.e. the output of \fB\-\-print\-architecture\fP)
+is always part of that list.
+.TP
+.B \-\-remove\-architecture \fIarchitecture\fP
+Remove \fIarchitecture\fP from the list of architectures for which packages
+can be installed without using \fB\-\-force\-architecture\fP. If the
+architecture is currently in use in the database then the operation will
+be refused, except if \fB\-\-force\-architecture\fP is specified. The
+architecture \fBdpkg\fP is built for (i.e. the output of
+\fB\-\-print\-architecture\fP) can never be removed from that list.
.TP
.B \-\-print\-architecture
Print architecture of packages \fBdpkg\fP installs (for example, i386).
@@ -572,12 +585,6 @@ each other. Both are processed in the given order, with
the last rule that
matches a file name making the decision.
.RE
.TP
-.B \-\-foreign\-architecture \fIarchitecture\fP
-Add \fIarchitecture\fP to the list of architectures for which packages can
-be installed without using \fB\-\-force\-architecture\fP, in addition to
-the architecture \fBdpkg\fP is built for (i.e.: the output of
-\fB\-\-print\-architecture\fP).
-.TP
\fB\-\-status\-fd \fR\fIn\fR
Send machine-readable package status and progress information to file
descriptor \fIn\fP. This option can be specified multiple times. The
diff --git a/src/enquiry.c b/src/enquiry.c
index 0eebf11..5b661b5 100644
--- a/src/enquiry.c
+++ b/src/enquiry.c
@@ -484,6 +484,8 @@ print_foreign_arches(const char *const *argv)
if (*argv)
badusage(_(--%s takes no arguments), cipaction-olong);
+ dpkg_arch_load_list();
+
for (arch = dpkg_arch_get_list(); arch; arch = arch-next) {
if (arch-type != arch_foreign)
continue;
diff --git a/src/main.c b/src/main.c
index 27924cf..4ed6ee1 100644
--- a/src/main.c
+++ b/src/main.c
@@ -104,6 +104,8 @@ usage(const struct cmdinfo *ci, const char *value)
-l|--list [pattern ...]List packages concisely.\n
-S|--search pattern ...Find package(s) owning file(s).\n
-C|--audit Check for broken package(s).\n
+ --add-architecture archAdd arch to the list of architectures.\n
+ --remove-architecture arch Remove arch from the list of
architectures.\n
--print-architecture Print dpkg architecture.\n
--print-foreign-architecturesPrint allowed foreign architectures.\n
--compare-versions a op b Compare version numbers - see below.\n
@@ -133,8 +135,6 @@ usage(const struct cmdinfo *ci, const char *value)
--instdir=directory Change installation dir without changing admin
dir.\n
--path-exclude=pattern
[SCM] dpkg's main repository branch, master, updated. 1.16.1.2-180-g4cde802
The following commit has been merged in the master branch:
commit 4cde802d703fac429fb3837a73c570046f1f698a
Author: Guillem Jover guil...@debian.org
Date: Tue Nov 15 21:59:17 2011 +0100
dpkg: Add architecture checks to --audit
diff --git a/src/enquiry.c b/src/enquiry.c
index 5b661b5..330bcdf 100644
--- a/src/enquiry.c
+++ b/src/enquiry.c
@@ -66,6 +66,14 @@ bsyn_status(struct pkginfo *pkg, const struct badstatinfo
*bsi)
return (int)pkg-status == bsi-value;
}
+static bool
+bsyn_arch(struct pkginfo *pkg, const struct badstatinfo *bsi)
+{
+ if (pkg-status stat_halfinstalled)
+return false;
+ return pkg-installed.arch-type == (enum dpkg_arch_type)bsi-value;
+}
+
static const struct badstatinfo badstatinfos[]= {
{
.yesno = bsyn_reinstreq,
@@ -110,6 +118,21 @@ static const struct badstatinfo badstatinfos[]= {
has not yet been done. Trigger processing can be requested using\n
dselect or dpkg --configure --pending (or dpkg --triggers-only):\n)
}, {
+.yesno = bsyn_arch,
+.value = arch_none,
+.explanation = N_(The following packages do not have an architecture:\n)
+ }, {
+.yesno = bsyn_arch,
+.value = arch_illegal,
+.explanation = N_(The following packages have an illegal architecture:\n)
+ }, {
+.yesno = bsyn_arch,
+.value = arch_unknown,
+.explanation = N_(
+The following packages have an unknown foreign architecture, which will\n
+cause dependency issues on front-ends. This can be fixed by registering\n
+the foreign architecture with dpkg --add-architecture:\n)
+ }, {
.yesno = NULL
}
};
--
dpkg's main repository
--
To UNSUBSCRIBE, email to debian-dpkg-cvs-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
[SCM] dpkg's main repository branch, master, updated. 1.16.1.2-180-g4cde802
The following commit has been merged in the master branch:
commit 1c1c2f7dc4b191f665f7cf7d8f70e7b66f942212
Author: Guillem Jover guil...@debian.org
Date: Tue Nov 15 21:59:17 2011 +0100
libdpkg: Add new dpkg_arch database interface
The arch database will store all known architectures in the file
«/var/lib/dpkg/arch», this includes the native architecture dpkg
was built for, and all registered foreign architectures.
diff --git a/lib/dpkg/arch.c b/lib/dpkg/arch.c
index 9a9c56c..856158f 100644
--- a/lib/dpkg/arch.c
+++ b/lib/dpkg/arch.c
@@ -24,15 +24,23 @@
#include compat.h
#include assert.h
+#include limits.h
#include ctype.h
#include string.h
+#include stdbool.h
+#include stdlib.h
+#include stdio.h
#include dpkg/i18n.h
#include dpkg/ehandle.h
+#include dpkg/dpkg.h
#include dpkg/dpkg-db.h
+#include dpkg/dir.h
#include dpkg/varbuf.h
#include dpkg/arch.h
+#define DPKG_DB_ARCH_FILE arch
+
/**
* Verify if the architecture name is valid.
*
@@ -98,6 +106,7 @@ static struct dpkg_arch arch_item_native = {
};
static struct dpkg_arch *arch_head = arch_item_native;
static struct dpkg_arch *arch_builtin_tail = arch_item_any;
+static bool arch_list_dirty;
static struct dpkg_arch *
dpkg_arch_new(const char *name, enum dpkg_arch_type type)
@@ -202,6 +211,7 @@ void
dpkg_arch_reset_list(void)
{
arch_builtin_tail-next = NULL;
+ arch_list_dirty = false;
}
void
@@ -213,3 +223,100 @@ varbuf_add_archqual(struct varbuf *vb, const struct
dpkg_arch *arch)
varbuf_add_char(vb, ':');
varbuf_add_str(vb, arch-name);
}
+
+/**
+ * Add a new foreign dpkg_arch architecture.
+ */
+struct dpkg_arch *
+dpkg_arch_add(const char *name)
+{
+ struct dpkg_arch *arch;
+
+ arch = dpkg_arch_find(name);
+ if (arch-type == arch_unknown) {
+ arch-type = arch_foreign;
+ arch_list_dirty = true;
+ }
+
+ return arch;
+}
+
+/**
+ * Remove a foreign dpkg_arch architecture.
+ */
+void
+dpkg_arch_remove(struct dpkg_arch *arch_remove)
+{
+ struct dpkg_arch *arch;
+
+ for (arch = arch_builtin_tail; arch-next; arch = arch-next) {
+ if (arch-next-type != arch_foreign)
+ continue;
+
+ if (arch-next == arch_remove) {
+ arch-next = arch-next-next;
+ arch_list_dirty = true;
+ }
+ }
+}
+
+/**
+ * Load the architecture database.
+ */
+void
+dpkg_arch_load_list(void)
+{
+ FILE *fp;
+ char *archfile;
+ char archname[_POSIX2_LINE_MAX];
+
+ archfile = dpkg_db_get_path(DPKG_DB_ARCH_FILE);
+ fp = fopen(archfile, r);
+ free(archfile);
+ if (fp == NULL) {
+ arch_list_dirty = true;
+ return;
+ }
+
+ while (fgets_checked(archname, sizeof(archname), fp, archfile) = 0)
+ dpkg_arch_add(archname);
+
+ fclose(fp);
+}
+
+/**
+ * Save the architecture database.
+ */
+void
+dpkg_arch_save_list(void)
+{
+ struct atomic_file *file;
+ struct dpkg_arch *arch;
+ char *archfile;
+
+ if (!arch_list_dirty)
+ return;
+
+ archfile = dpkg_db_get_path(DPKG_DB_ARCH_FILE);
+ file = atomic_file_new(archfile, 0);
+ atomic_file_open(file);
+
+ for (arch = arch_head; arch; arch = arch-next) {
+ if (arch-type != arch_foreign arch-type != arch_native)
+ continue;
+
+ if (fprintf(file-fp, %s\n, arch-name) 0)
+ ohshite(_(error writing to architecture list));
+ }
+
+ atomic_file_sync(file);
+ atomic_file_close(file);
+ atomic_file_commit(file);
+ atomic_file_free(file);
+
+ dir_sync_path(dpkg_db_get_dir());
+
+ arch_list_dirty = false;
+
+ free(archfile);
+}
diff --git a/lib/dpkg/arch.h b/lib/dpkg/arch.h
index fbb9268..23f532e 100644
--- a/lib/dpkg/arch.h
+++ b/lib/dpkg/arch.h
@@ -51,6 +51,11 @@ struct dpkg_arch *dpkg_arch_get(enum dpkg_arch_type type);
struct dpkg_arch *dpkg_arch_get_list(void);
void dpkg_arch_reset_list(void);
+struct dpkg_arch *dpkg_arch_add(const char *name);
+void dpkg_arch_remove(struct dpkg_arch *arch);
+void dpkg_arch_load_list(void);
+void dpkg_arch_save_list(void);
+
void varbuf_add_archqual(struct varbuf *vb, const struct dpkg_arch *arch);
DPKG_END_DECLS
diff --git a/lib/dpkg/libdpkg.map b/lib/dpkg/libdpkg.map
index 41d3ad5..9f80069 100644
--- a/lib/dpkg/libdpkg.map
+++ b/lib/dpkg/libdpkg.map
@@ -191,6 +191,10 @@ LIBDPKG_PRIVATE {
dpkg_arch_get;
dpkg_arch_get_list;
dpkg_arch_reset_list;
+ dpkg_arch_add;
+ dpkg_arch_remove;
+ dpkg_arch_load_list;
+ dpkg_arch_save_list;
# Package struct handling
pkg_blank;
--
dpkg's main repository
--
To UNSUBSCRIBE, email to debian-dpkg-cvs-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
[SCM] dpkg's main repository branch, master, updated. 1.16.1.2-181-gc9bfb5c
The following commit has been merged in the master branch: commit c9bfb5c6ce37f4d2ccfef4ee5c41be21b8d07f7c Author: Sven Joachim svenj...@gmx.de Date: Mon Jan 2 11:24:46 2012 +0100 German dpkg translation update Update to 1018t. diff --git a/po/de.po b/po/de.po index bae6356..7849686 100644 --- a/po/de.po +++ b/po/de.po @@ -4,15 +4,15 @@ # Erich Schubert deb...@vitavonni.de, March 2001. # Michael Piefel pie...@debian.org, 2001, 2002, 2003, 2004, 2005. # Florian Ernst flor...@uni-hd.de, 2004. -# Sven Joachim svenj...@gmx.de, 2006, 2007, 2008, 2009, 2010, 2011. +# Sven Joachim svenj...@gmx.de, 2006, 2007, 2008, 2009, 2010, 2011, 2012. # Holger Wansing li...@wansing-online.de, 2010. # msgid msgstr Project-Id-Version: Debian dpkg 1.16.2~\n Report-Msgid-Bugs-To: debian-d...@lists.debian.org\n -POT-Creation-Date: 2011-11-23 10:09+0100\n -PO-Revision-Date: 2011-11-23 10:30+0100\n +POT-Creation-Date: 2012-01-02 10:25+0100\n +PO-Revision-Date: 2012-01-02 11:22+0100\n Last-Translator: Sven Joachim svenj...@gmx.de\n Language-Team: German debian-l10n-ger...@lists.debian.org\n Language: de\n @@ -47,20 +47,70 @@ msgstr Abfragen von ar-Element-Datei (%s) mit fstat fehlgeschlagen msgid ar member file (%s) msgstr ar-Element-Datei (%s) -#: lib/dpkg/arch.c:55 lib/dpkg/parsehelp.c:134 +#: lib/dpkg/arch.c:64 lib/dpkg/parsehelp.c:134 msgid may not be empty string msgstr darf keine leere Zeichenkette sein -#: lib/dpkg/arch.c:57 +#: lib/dpkg/arch.c:66 msgid must start with an alphanumeric msgstr muss mit alphanumerischem Zeichen beginnen -#: lib/dpkg/arch.c:64 lib/dpkg/parsehelp.c:145 +#: lib/dpkg/arch.c:73 lib/dpkg/parsehelp.c:142 #, c-format msgid character `%c' not allowed (only letters, digits and characters `%s') msgstr Zeichen »%c« nicht erlaubt (nur Buchstaben, Ziffern und die Zeichen »%s«) +#: lib/dpkg/arch.c:309 +msgid error writing to architecture list +msgstr Fehler beim Schreiben der Architekturliste + +#: lib/dpkg/atomic-file.c:57 +#, c-format +msgid unable to create new file '%.250s' +msgstr Neue Datei »%.250s« kann nicht angelegt werden + +#: lib/dpkg/atomic-file.c:68 +#, c-format +msgid unable to write new file '%.250s' +msgstr Neue Datei »%.250s« kann nicht geschrieben werden + +#: lib/dpkg/atomic-file.c:70 +#, c-format +msgid unable to flush new file '%.250s' +msgstr Neue Datei »%.250s« kann nicht zurückgeschrieben werden + +#: lib/dpkg/atomic-file.c:72 +#, c-format +msgid unable to sync new file '%.250s' +msgstr Neue Datei »%.250s« kann nicht synchronisiert werden + +#: lib/dpkg/atomic-file.c:81 +#, c-format +msgid unable to close new file `%.250s' +msgstr Neue Datei »%.250s« kann nicht geschlossen werden + +#: lib/dpkg/atomic-file.c:92 +#, c-format +msgid error removing old backup file '%s' +msgstr Fehler beim Entfernen der alten Sicherungsdatei »%s« + +#: lib/dpkg/atomic-file.c:94 +#, c-format +msgid error creating new backup file '%s' +msgstr Fehler beim Anlegen der neuen Sicherungsdatei »%s« + +#: lib/dpkg/atomic-file.c:103 lib/dpkg/atomic-file.c:105 +#: lib/dpkg/triglib.c:433 src/remove.c:286 src/remove.c:377 +#, c-format +msgid cannot remove `%.250s' +msgstr »%.250s« kann nicht entfernt werden + +#: lib/dpkg/atomic-file.c:115 +#, c-format +msgid error installing new file '%s' +msgstr Fehler beim Installieren der neuen Datei »%s« + #: lib/dpkg/buffer.c:196 #, c-format msgid failed to read on buffer copy for %s @@ -249,38 +299,38 @@ msgstr Auf den Statusbereich von dpkg kann nicht zugegriffen werden msgid operation requires read/write access to dpkg status area msgstr Operation benötigt Lese-/Schreibrechte für den Statusbereich von dpkg -#: lib/dpkg/dbmodify.c:315 +#: lib/dpkg/dbmodify.c:317 #, c-format msgid failed to remove my own update file %.255s msgstr Löschen der eigenen Update-Datei %.255s fehlgeschlagen -#: lib/dpkg/dbmodify.c:353 +#: lib/dpkg/dbmodify.c:355 #, c-format msgid unable to write updated status of `%.250s' msgstr Aktualisierter Status von »%.250s« kann nicht geschrieben werden -#: lib/dpkg/dbmodify.c:355 +#: lib/dpkg/dbmodify.c:357 #, c-format msgid unable to flush updated status of `%.250s' msgstr Puffer des aktualisierten Status von »%.250s« kann nicht geleert werden -#: lib/dpkg/dbmodify.c:357 +#: lib/dpkg/dbmodify.c:359 #, c-format msgid unable to truncate for updated status of `%.250s' msgstr Für aktualisierten Status von »%.250s« kann nicht abgeschnitten werden -#: lib/dpkg/dbmodify.c:360 +#: lib/dpkg/dbmodify.c:362 #, c-format msgid unable to fsync updated status of `%.250s' msgstr Aktualisierter Status von »%.250s« kann nicht synchronisiert werden -#: lib/dpkg/dbmodify.c:362 +#: lib/dpkg/dbmodify.c:364 #, c-format msgid unable to close updated status of `%.250s' msgstr Aktualisierter Status von »%.250s« kann nicht geschlossen werden -#: lib/dpkg/dbmodify.c:365 +#: lib/dpkg/dbmodify.c:367 #, c-format msgid unable to install updated status of `%.250s' msgstr Aktualisierter Status von
Re: Bug#571776: document symbols
Hello folks, I took some time today and wrote a first draft of a new section of Policy documenting symbols files, and the revisions to shlibs for their interaction. Please review. There's quite a lot of material here, including details from dpkg-shlibdeps, dpkg-gensymbols, and deb-symbols documentation as well as additional requirements and recommendations around how to maintain the minimal-version field. I tried sending a unified diff, but the new sections are largely unreadable since they're intermixed with the old sections being removed. Hence, for review purposes, here are the symbols and shlibs sections in their entirety, followed by a diff for the changes elsewhere in Policy. You can also refer to branch bug571776-rra in the Policy repository. sect id=sharedlibs-symbols headingDependencies between the library and other packages - the ttsymbols/tt system/heading p If a package contains a binary or library which links to a shared library, we must ensure that, when the package is installed on the system, all of the libraries needed are also installed. These dependencies must be added to the binary package when it is built, since they may change based on which version of a shared library the binary or library was linnked with. To allow these dependencies to be constructed, shared libraries must provide either a filesymbols/file file or a fileshlibs/file file, which provide information on the package dependencies required to ensure the presence of this library. Any package which uses a shared library must use these files to determine the required dependencies when it is built. /p p fileshlibs/file files were the original mechanism for handling library dependencies. They are documented in ref id=sharedlibs-shlibdeps. filesymbols/file files, documented in this section, are recommended for most packages, since they provide dependency information for each exported symbol and therefore generate more accurate dependencies for binaries that do not use symbols from newer versions of the shared library. However, fileshlibs/file files must be used for udebs. Packages which provide a filesymbols/file file are not required to provide a fileshlibs/file file. /p p When a package that contains any shared libraries or compiled binaries is built, it must run prgndpkg-shlibdeps/prgn on each shared library and compiled binary to determine the libraries used and hence the dependencies needed by the package.footnote prgndpkg-shlibdeps/prgn will use a program like prgnobjdump/prgn or prgnreadelf/prgn to find the libraries and the symbols in those libraries directly needed by the binaries or shared libraries in the package. /footnote /p p We say that a binary ttfoo/tt emdirectly/em uses a library ttlibbar/tt if it is explicitly linked with that library (that is, the library is listed in the ELF ttNEEDED/tt attribute, caused by adding tt-lbar/tt to the link line when the binary is created). Other libraries that are needed by ttlibbar/tt are linked emindirectly/em to ttfoo/tt, and the dynamic linker will load them automatically when it loads ttlibbar/tt. A package should depend on the libraries it directly uses, but not the libraries it indirectly uses. The dependencies for those libraries will automatically pull in the other libraries. prgndpkg-shlibdeps/prgn will handle this logic automatically, but package maintainers need to be aware of this distinction between directly and indirectly using a library if they have to override its results for some reason. footnote A good example of where this helps is the following. We could update ttlibimlib/tt with a new version that supports a new graphics format called dgf (but retaining the same major version number) and depends on ttlibdgf/tt. If we used prgnldd/prgn to add dependencies for every library directly or indirectly linked with a binary, every package that uses ttlibimlib/tt would need to be recompiled so it would also depend on ttlibdgf/tt or it wouldn't run due to missing symbols. Since dependencies are only added based on ELF ttNEEDED/tt attribute, packages using ttlibimlib/tt can rely on ttlibimlib/tt itself having the dependency on ttlibdgf/tt and so they would not need rebuilding. /footnote /p p In the
Bug#613428: dpkg --force-unsafe-io still calls fsync()
[ Mike Hommey ] While this is stricly true, there are still two fsync()s occuring on each package unpack, making the whole thing still slow when installing many packages at a time. These happen for /var/lib/dpkg/updates and /var/lib/dpkg/tmp.ci. [ Raphael Hertzog ] This is on purpose. Can you explain in which situation where --force-unsafe-io is used that you believe these fsync()s to be an advantage? I've tried to come up with such scenarios without any luck so far. The users of --force-unsafe-io seem to be those that know that if something go wrong during installation, they scratch everything and start again, and finishing quickly is more important than handling power outages. One example is building live CDs. Another is installing the system for the first time. A third is creating chroots for testing. In all these cases any power outage or other system failure will make one erase everything and start over, and there is no need for dpkg to keep an consistent state. I would love my distro upgrade test to become faster and thus hope also these fsyncs can go away. I install stable in a chroot, dist-upgrade to testing, and check the rsult. If the something go wrong I remove the chroot and start over, so there is no need for any sync to disk. :) -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613428: dpkg --force-unsafe-io still calls fsync()
Petter Reinholdtsen wrote: The users of --force-unsafe-io seem to be those that [...] In retrospect, introducing --force-unsafe-io was probably a mistake. Making sure to always call a wrapper function that behaves just like fsync() but can be disabled would be a maintenance burden for almost no benefit, given that eatmydata exists. The current semantics are at least distinct from eatmydata, though it's not obvious to me that it is a very useful distinction. (I guess the idea is that it is for situations in which you can easily detect corruption of individual installed packages and reinstall them, while the internal database is still precious.) Hope that clarifies a little, Jonathan -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613428: dpkg --force-unsafe-io still calls fsync()
Hi, On Mon, 02 Jan 2012, Petter Reinholdtsen wrote: [ Mike Hommey ] While this is stricly true, there are still two fsync()s occuring on each package unpack, making the whole thing still slow when installing many packages at a time. These happen for /var/lib/dpkg/updates and /var/lib/dpkg/tmp.ci. [ Raphael Hertzog ] This is on purpose. Can you explain in which situation where --force-unsafe-io is used that you believe these fsync()s to be an advantage? I've tried to come up with such scenarios without any luck so far. This is an option that we wish it did not exist. The users of --force-unsafe-io seem to be those that know that if something go wrong during installation, they scratch everything and start again, and finishing quickly is more important than handling power outages. One example is building live CDs. Another is installing the system for the first time. A third is creating chroots for testing. In all these cases any power outage or other system failure will make one erase everything and start over, and there is no need for dpkg to keep an consistent state. I would love my distro upgrade test to become faster and thus hope also these fsyncs can go away. I install stable in a chroot, dist-upgrade to testing, and check the rsult. If the something go wrong I remove the chroot and start over, so there is no need for any sync to disk. :) The proper approach is to enhance your testing tools to use eatmydata to really disable all fsync() and not only those of dpkg. --force-unsafe-io has not been meant for those use case at all, it was meant for some users to gain back some performance lost on supplementary fsync() that have been added to dpkg. It was not meant to disable all fsync() and in particular not those on the database. Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613428: dpkg --force-unsafe-io still calls fsync()
Thank you for the quick reply. I wish you a happy new year. :) [Raphael Hertzog] This is an option that we wish it did not exist. OK. Still do not explain to me in what situation or use case it is useful drop fsync() for the package files while still using fsync() on /var/lib/dpkg/updates and /var/lib/dpkg/tmp.ci. I assume there is such usecase, given that the option is working the way it is. The proper approach is to enhance your testing tools to use eatmydata to really disable all fsync() and not only those of dpkg. It is not really possible to do this without rewriting all of Debian to allow it. While adding a file to gain a similar effect is possible. I tried to get eatmydata to work, but there are just too many packages that would need to change for it to have the desired effect. --force-unsafe-io has not been meant for those use case at all, it was meant for some users to gain back some performance lost on supplementary fsync() that have been added to dpkg. It was not meant to disable all fsync() and in particular not those on the database. I would expect these users to also want the extra performance gained by dropping the left behind fsyncs()? Why should this use case want the remaining fsync()s in place? -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613428: dpkg --force-unsafe-io still calls fsync()
On Mon, 02 Jan 2012, Petter Reinholdtsen wrote: I would expect these users to also want the extra performance gained by dropping the left behind fsyncs()? Why should this use case want the remaining fsync()s in place? Because they care about the integrity of their system? We de not want to make it easy to corrupt your dpkg database. Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613428: dpkg --force-unsafe-io still calls fsync()
[Raphael Hertzog] Because they care about the integrity of their system? We de not want to make it easy to corrupt your dpkg database. Your comment do not make sense to me. I fail to understand how those caring about the integrity of their system during the dpkg run would use --force-unsafe-io. At least I only use it if I care about speed, and would be happy to start again if something went wrong half-way through the installation. When I use it, I do not care about the integrity, and neither do those building live CDs. :) Anyway, hopefully someone some time in the future will come up with a usecase that could make me understand when it is useful to not fsync the package files and only fsync the dpkg database. -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653846: Please add an option for dpkg-buildflags to emit a different optimization level
On Mon, Jan 02, 2012 at 01:50:47AM -0600, Jonathan Nieder wrote: Raphael Hertzog wrote: On Sat, 31 Dec 2011, Jonathan Nieder wrote: It's perhaps ugly, but DEB_CFLAGS_MAINT_APPEND=-Os works fine for me. Why would it be ugly? I think that's the correct interface to change the optimization level. Because the resulting compiler command line contains both -O2 and -Os. But yes, I agree it's less ugly than any alternative I can imagine. Is the evaluation order of GCC options properly specified, i.e. is there a guarantee that -Os overrides the previous -O2 or is this undefined behaviour, which just happens to do the correct thing in this case? If not, this has the potential for subtle bugs and build failures with new GCC releases. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653846: Please add an option for dpkg-buildflags to emit a different optimization level
Moritz Muehlenhoff wrote: Is the evaluation order of GCC options properly specified, i.e. is there a guarantee that -Os overrides the previous -O2 Yes. (From the manual: If you use multiple -O options, with or without level numbers, the last such option is the one that is effective.) -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653846: Please add an option for dpkg-buildflags to emit a different optimization level
On Mon, Jan 02, 2012 at 12:59:16PM -0600, Jonathan Nieder wrote: Moritz Muehlenhoff wrote: Is the evaluation order of GCC options properly specified, i.e. is there a guarantee that -Os overrides the previous -O2 Yes. (From the manual: If you use multiple -O options, with or without level numbers, the last such option is the one that is effective.) Thanks. That's a good solution, then. I'll add this to the hardening conversion docs I'm planning to work on next weekend. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
