Hi Brandon,
On Mon, Feb 20, 2012 at 10:38:05AM -0500, Brandon Phelps wrote:
I am putting together some packages for our internal servers and have an
SQL file that I need to run on the database during the package install.
I realize I could put the .sql file in /tmp and simply remove it after
/lurk
Hi Sam,
On Mon, May 30, 2011 at 03:51:32PM +0100, Sam Dunne wrote:
One diversion per line
Blank lines and lines with # are comments
Two fields per diversion seperated by whitespace (SOURCE DESTINATION)
Does this mean it will not be possible to divert a file when the source
or
On Mon, May 09, 2011 at 12:36:28PM +0200, Raphael Hertzog wrote:
[1] checking the multi-arch status of the package's previous version to
determine the conffiledb path at appropriate points in the code,
assuming that can be done.
I have not looked into details but I don't see why
On Fri, May 06, 2011 at 10:58:46AM -0500, Jonathan Nieder wrote:
I think pkg:arch would suffice instead of pkg, right?
Yes, probably. I'm not sure whether arch:all packages are currently
tied to a specific arch.
I'd think that only one instance of arch:all could be installed, but I
haven't
Hiya,
Once again, everything prefixed with IIRC and it may no longer
be the case.
On Fri, May 06, 2011 at 02:49:30AM -0500, Jonathan Nieder wrote:
debug is now part of libdpkg so I left that one out.
help.c describes itself as help.c - various helper routines, which
doesn't seem so far from
On Fri, May 06, 2011 at 02:59:52AM -0500, Jonathan Nieder wrote:
Ah, memories. The main piece to revisit might be what sort of
identifier to use for pkg in these modern days of multiarch. I also
I think pkg:arch would suffice instead of pkg, right?
think there was some talk about atomic
On Fri, May 06, 2011 at 03:11:30AM -0500, Jonathan Nieder wrote:
It might make sense to consider the patches up to here as something
to polish and make mergeable to start out. It would already be useful.
Agreed :)
What happens if the previously configured version was installed before
On Fri, May 06, 2011 at 03:24:47AM -0500, Jonathan Nieder wrote:
Ah, now the memories come back! I find the While this may not have an
immediate benefit mentioned above convincing. I am not happy about
storing extra data that does not seem very relevant, just in case.
The idea IIRC was that
On Fri, May 06, 2011 at 03:19:09AM -0500, Jonathan Nieder wrote:
Is diff3 -m the state of the art for this? Well, it will do to
start. In the long term maybe some people will want to use some other
tool to perform the merge, like RCS merge or something Config::Model
based.
I think a very
On Fri, May 06, 2011 at 10:24:20AM +0200, Guillem Jover wrote:
Thanks for picking this up again! Some time ago I started a rework of
the series, but didn't finish it up. I've pushed a branch now [0] with
those changes, rebased against master, but take into account they only
build and not even
Hiya,
Preface: everything here should be prefixed with a very fuzzy IIRC.
On Wed, May 04, 2011 at 03:12:57PM -0500, Dustin Kirkland wrote:
In any case, I see that bug 32877 has an updated patch as of Wed, 23
Mar 2011, from Vasily i. Redkin, but I don't see any feedback yet on
that latest
hi jonathan,
On Sun, Jun 27, 2010 at 03:45:47PM -0500, Jonathan Nieder wrote:
I agree with this. In the past it seemed like you were mostly
interested in hearing from people with the ability to commit changes,
no, i wouldn't say so. however, there is/was a fairly strict intersection
of those
On Sun, Jun 27, 2010 at 03:23:14PM -0500, Jonathan Nieder wrote:
This is the workaround needed to reset the configuration of some
debian packages who need them. There are also other workarounds
I agree. It would be nice to have
dpkg-deb --extract foo.deb / /etc
to extract the
On Tue, Apr 06, 2010 at 02:53:20PM +0200, Raphael Hertzog wrote:
I will try to merge something during next week-end hopefully. Until then I
would be glad if some people could review Joey's old proposal from
http://lists.debian.org/debian-dpkg/2008/01/msg00143.html
to see if there are problems
hi guillem,
i'll try to answer these in order, here's the first to look over
while i start looking over the next.
On Sun, Feb 07, 2010 at 08:24:55PM +0100, Guillem Jover wrote:
On Mon, 2009-12-14 at 08:27:32 +0100, Sean Finney wrote:
The layout pattern for the conffile database
On Sun, Feb 07, 2010 at 08:51:27PM +0100, Guillem Jover wrote:
On a successful merge, the merge output replaces the conffile, and dpkg
continues as if the admin had selected to keep the old conffile. On merge
failure the admin is informed of the failure and the the conflict prompt
is
On Mon, Feb 08, 2010 at 02:55:49AM +0100, Guillem Jover wrote:
On Mon, 2009-12-14 at 08:27:37 +0100, Sean Finney wrote:
When a merge is successful, store the common ancestor of the merge (the
pristine version of the conffile from the previous package version) in
a special location. While
dpkg now ships with a directory (/var/lib/dpkg/conffiles) for holding the
dist versions of packaged conffiles and other conffiledb meta-information.
---
debian/dpkg.dirs |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 debian/dpkg.dirs
diff --git a/debian/dpkg.dirs
A small number of functions from help.c are required for outside-of-dpkg
functioning of the conffiledb routines. As we want to be able to have
functional unit tests as well as to use these routines in other cmdline
programs (such as a hypothetical dpkg-conffile utility), we need to move
these
In tarobject() (src/archives.c), some slight of hand is performed with
the backend pipe of the struct tarcontext to intercept conffiles and
place a copy in the available conffile database for the package before
extracting it as usual.
In deferred_configure (src/configure.c), the conffiledb of the
parts of the conffile database.
+ *
+ * Copyright © 2009 Sean Finney sean...@debian.org
+ *
+ * This is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License
to dpkg's UI behavior so I felt it should be left for further discussion
on how to proceed there.
Sean Finney (7):
Split some useful functions from help.c to (new) util.c
Conffile database handling functions
Include the conffiledb directory in the dpkg deb package
Hook conffile database
A new option is presented to the user in the conffile resolution prompt,
offering to show the diff between the previous dist version of the conffile
and the new dist version of the conffile. This can be useful for the local
admin to know what has changed in the latest version of the package in the
The conflict resolution prompt has been updated with a new option for
automatic merging:
M : attempt to automatically merge the differences
This functions by performing a 3-way diff using the new conffile, the
currently-installed conffile, and the pristine version of the conffile
(belated response),
On Thu, Nov 19, 2009 at 10:17:13PM -0600, Jonathan Nieder wrote:
Is your current code in a git repo somewhere? I would like to try it
out, even if the filesystem layout might change later, to see what it
is like to use and if I run into any issues.
(I would be happy to
okay, some comments to the comments...
On Thu, Nov 19, 2009 at 07:44:51AM +0100, Guillem Jover wrote:
On Mon, 2009-11-09 at 23:26:27 +0100, sean finney wrote:
On Fri, Nov 06, 2009 at 08:48:43AM +0100, Guillem Jover wrote:
+/**
+ * @file conffiledb.h
The annotated tag, conffile-fun-poc-1 has been created
at bcd18511467d15d322d1826fc6fa0ca0e1a6f3b9 (tag)
tagging 4629752eb4463292bd879dba048dfd5c4ca7ca76 (commit)
replaces 1.14.16.6
tagged by Sean Finney
on Mon Mar 3 23:03:54 2008 +0100
- Shortlog
The annotated tag, conffile-fun-poc-2 has been created
at a407179e6b2723313e3b6434b8db27c5c7027922 (tag)
tagging f13ac4c057a04c77ad1740166f81cdc633cd80f3 (commit)
replaces conffile-fun-poc-1
tagged by Sean Finney
on Sat Mar 8 13:27:33 2008 +0100
- Shortlog
The annotated tag, debconf-fun-poc-1 has been created
at b50bc8e2f10199c66e9f25e8c8c420096767e426 (tag)
tagging 389e0b5d87ab155311ede18d0a259e4433b67d36 (commit)
replaces 1.14.16.6
tagged by Sean Finney
on Sun Mar 16 19:53:06 2008 +0100
- Shortlog
another bus ride, another few comments to catch up with...
On Sun, Oct 25, 2009 at 03:50:44PM -0500, Jonathan Nieder wrote:
+/** Prompt the user for how to resolve a conffile conflict
There are not many of these documentation comments, but adding some
seems like a good idea, especially if
hi jonathan,
thanks for your feedback on this and the previous patches.
before going any further, i'd like to point out that i'm still waiting
for feedback from guillem, and i don't plan on doing any further work
on this until i hear at least something from him indicating that he's
interested
(note: this information is largely duplicative of the comments in conffiledb.h)
The files conffiledb.{c,h} define a set of routines for adding and removing
stored versions of the pristine conffiles as shipped in their respective
packages.
Such an implementation allows for some neat features in
In process_archive() (src/processarc.c), clean out the staged (-new)
version of the package's conffile database.
In tarobject() (src/archives.c), some slight of hand is performed with
the backend pipe of the struct tarcontext to intercept conffiles and
place a copy in the staged (new) conffile
The conflict resolution prompt has been updated with a new option for
automatic merging:
Configuration file `file'
== Modified (by you or by a script) since installation.
== Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I
hi,
On Mon, Oct 05, 2009 at 01:32:49PM +0200, Goswin von Brederlow wrote:
in a recent discussion on irc we pondered the possibility of
maintaining /etc in an RCS (git in that case). Two ideas then came up:
i think there's a few solutions that come close to this already (etcgit
being one off
hi again,
On Mon, Oct 05, 2009 at 01:38:39PM +0200, Goswin von Brederlow wrote:
In the thread to your patch series for conffile tracking I saw
mentioned that you have:
- current conffile
- old orig conffile
- new orig conffile
- last successfully installed conffile
the current and old
okay, before i do any proper coding on a cmdline utility, i thought we
should work out the details of the cmdline interface. this is an initial
draft of what i was thinking, comments requested :)
sean
NAME
dpkg-conffile - inspect status and conttents of conffiles
On Sat, Oct 03, 2009 at 04:00:42PM +0200, sean finney wrote:
RETURN CODE
For all modes but -d/--diff, the command returns 0 on success and
nonzero on error. When diffing a file
should end in ...the return code of the underlying call to diff(1) is returned.
signature.asc
, 2009 at 08:19:48AM +0200, Raphael Hertzog wrote:
On Mon, 28 Sep 2009, Sean Finney wrote:
+ ohshite(_(unable to stat installed file `%.250s'), source);
+ ohshite(_(unable to change ownership of target file`%.250s'),
+ target);
+ ohshite
conffiles.{c,h} defines a set of routines for adding and removing
stored versions of the pristine conffiles as shipped in their respective
packages.
such an implementation allows for some neat features in the future,
such as:
- 3-way merging of conffile changes
- showing the old-new delta for
From: Sean Finney sean...@seanius.net
this function will be useful for other parts of dpkg, so the function
has been moved to a more sensible location, the static qualifier removed,
and its name appropriately prefixed.
---
lib/dpkg/path.c | 59
in order to provide an interface into the conffile db api, it's required
to know the package name that owns the conffile. since this is a static
function and the package name is available in all places that the function
is used, this is a fairly easy fix.
---
src/configure.c |9 +
1
the conflict resolution prompt has been updated with a new option for
automatic merging:
Configuration file `file'
== Modified (by you or by a script) since installation.
== Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I
in process_archive() (src/processarc.c), clean out the staged (-new)
version of the package's conffile database.
in tarobject() (src/archives.c), some slight of hand is performed with
the backend pipe of the struct tarcontext to intercept conffiles and
place a copy in the staged (new) conffile
, mostly changing the
interface of internal static functions and renaming/exposing other static
functions that are needed for the features in the patches that follow.
Sean Finney (6):
move quote_filename into lib/dpkg/path.{c,h} as path_quote_filename
move copyfileperms to non-static
this functionality is also needed by the conffile handling code to ensure
that the merge output is stored in a file with the same permissions as
the original conffile, preventing the accidental oppurtunity for
unintended information disclosure.
therefore the function is moved into a new library
hi guys,
*almost* done with the rebase/squash/split stuff for the conffile database
changes, but now i've stumbled into a problem on which i think i should
get a bit of feedback. previously, i had this function to create the
md5sum of a filename:
/* calculate the md5sum of the contents of the
hi guillem,
On Sat, Sep 19, 2009 at 05:00:15PM +0200, Guillem Jover wrote:
-quote_filename(char *buf, int size, char *s)
+char* quote_filename(char *buf, int size, char *s)
Could you move this to lib/dpkg/path.[ch] instead, with the proper
prefix rename, etc?
sure thing. fyi the
hi guillem,
On Fri, Aug 21, 2009 at 08:20:35AM +0200, Guillem Jover wrote:
- Merge back apt-exttracttemplates.
- Finish to draft the spec for the debconf integration:
http://wiki.debian.org/DpkgDebconfIntegration
- Implement invoke hooks.
- Implement db control-path printing.
hi guys,
On Mon, Aug 31, 2009 at 03:17:35AM -0400, David Benjamin wrote:
I also remember some experimental work of Sean Finney who put a cache in
a sqlite db. You might be interested to look up in Google and/or in the
BTS if you can find out this old patch.
Thanks! I will look at this more
hi guys,
(replying to -dpkg instead of -release for this one)
do you guys have any plans on moving forward with the conffile tracking
support? i will generally have more time than usual this fall for debian
related work so if there's a will to do it there's also a way...
sean
hi bruno,
wow, looks like you spent some time thinking about this :)
i hope you don't mind, but i'm going to forward much of this on to the
dpkg developers list.
On Thu, Feb 26, 2009 at 11:01:31AM +0100, Bruno De Fraine wrote:
http://lists.debian.org/debian-dpkg/2008/04/msg00022.html
hey everyone,
(btw i'm subscribed to the list now, so feel free to stop cc'ing me)
i've summarized things up a bit here:
http://wiki.debian.org/Teams/Dpkg/Proposals/ConffileDatabase
like i say in the wiki page, the only real big question at this point is
which format to use, i.e.
hey everyone,
(please continue to cc me)
yet another itch i've been wanting to scratch for a while... having debconf
support in dpkg. i've made a proof of concept[1], the patches for which i'll
be posting to this thread shortly. there are still some open questions and
issues with the
+# internal script for debconf-based management of conffiles
+# calling convention:
+# dpkg-confprompt.sh pkg cfgfile reason
+# initial implementation by sean finney
+# copyright (c) 2008 sean finney [EMAIL PROTECTED]
+# this file may be used in accordance with the dpkg software copyright
+
+
+# debug
the promptconfaction() function now takes a first parameter of the package
name. in a future debconf interface, it may be helpful to have this (if
we decide to register the questions per package/conffile). at the least,
it can provide a little more information to the user via debconf, where
the
hiya,
On Saturday 08 March 2008 12:27:58 pm Martin Uecker wrote:
Please do not use a md5sum. Having the original conf file installed
as reference is usefull for the admin too and making the path a md5sum
just makes it harder too find. Having the full path is interesting for
other reasons,
---
src/conffiles.c | 24 +---
1 files changed, 9 insertions(+), 15 deletions(-)
diff --git a/src/conffiles.c b/src/conffiles.c
index db55538..96fdbd9 100644
--- a/src/conffiles.c
+++ b/src/conffiles.c
@@ -90,31 +90,25 @@ int conff_get_fd(const char *pkg, const char *path,
the pathname of the conffile is transformed into an md5sum, allowing for
a simpler conffile db implementation where conffiles are now found in:
admindir/conffiles{,-new,-old}/pkg/hash
---
src/conffiles.c | 51 ++-
1 files changed, 38
this is still kinda proof-of-conceptish, most notably
two things need to be resolved before finalizing:
- ensure that the conffile db references the right paths
during all accesses (i.e. the packaged conffile vs the
resolved conffile name).
- decide on the behavior/interface. currently if
izJWwKiwL6CGeytRRkItNwE=
=TTSe
-END PGP SIGNATURE-
From 3b36ceb9d1984dd5669efbf96670aeb74893e281 Mon Sep 17 00:00:00 2001
From: Sean Finney [EMAIL PROTECTED]
Date: Sat, 1 Mar 2008 09:44:09 +0100
Subject: [PATCH] small memory leak fixes
---
lib/dump.c |2 ++
src/help.c |1 +
2 files changed, 3
From: Sean Finney [EMAIL PROTECTED]
---
src/archives.c | 58
src/help.c | 57 +++
src/main.h |1 +
3 files changed, 58 insertions(+), 58 deletions(-)
diff --git a/src
hiya,
On Tuesday 04 March 2008 10:15:18 pm Ian Jackson wrote:
so, this past weekend i had a couple of 12-hour train rides and thus
some time to kill, and threw together a proof of concept for your
perusal. basically, every package has a subdirectory
admindir/conffiles/pkgext (where ext
hey dpkg peeps,
(please CC me, i'm not subscribed)
i spoke with a couple folks on irc about the idea of keeping the dist
version of conffiles on-disk somehow, and the general consensus was that it
seemed like a good idea but noone had the time to push it out of a todo list.
keeping the dist
Package: dpkg-dev
Version: 1.14.6
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
rangda[/home/sean/debian/libcompizconfig-0.52] /usr/bin/822-date
Can't locate controllib.pl in @INC (@INC contains: /etc/perl
/usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5
hi folks,
sorry for breaking the thread, but i'm not subscribed and i wasn't cc'd,
and my current MUA sucks.
from ian:
Well, I don't know if I still count as one of the `dpkg team' but I
think this is a terrible idea for lots of reasons. dpkg needs to be
very reliable; its databases must
On Sat, 2007-03-31 at 21:17 -0400, Jonathan Bastien-Filiatrault wrote:
The difference is drastic. One of the main concerns now is reliability. Does
anyone here know of any SQLite horror stories they might like to share ?
i don't have much to add on this, but i'd like to point out that there
On Sat, 2007-03-31 at 22:53 +0200, Florian Weimer wrote:
* sean finney:
as a plus, it would drastically reduce the amount of code in dpkg. the
hundreds of lines of code dedicated toe
scanning/reading/writing/parsing/representing the various *.list
*.md5sums etc could be reduced
hey folks,
(please cc me on responses, i'm not subscribed)
people have brought this up a few times but i haven't seen an answer
whether or not this is something you'd be interested in having. usually
the discussion seems to veer off to you should set foo on your
filesystem etc.
as others have
hey,
On Wed, May 11, 2005 at 04:23:26PM +0200, Christian Hammers wrote:
So we can fix the woody-sarge upgrade just by uploading a new
package to stable-proposed-updates and hoping that Joey makes a
new Woody update before the Sarge release, right, or am I missing something?
(not yet tested
On Wed, Mar 16, 2005 at 10:24:04PM +, Scott James Remnant wrote:
Because it's a 64-bit version of an already supported architecture.
Having ppc and ppc64 would be fine, as would having powerpc and
powerpc64. Having powerpc and ppc64 is inconsistent.
and deviating from an already
Package: dpkg-dev
Version: 1.10.20
Severity: wishlist
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
hey there, basically, i have this happen to me a whole lot:
dpkg-buildpackage: source package is $package
dpkg-buildpackage: source version is $version
dpkg-buildpackage: source maintainer is
72 matches
Mail list logo
