On Mon, 21 Jan 2008, Roger Leigh wrote:
> > Maybe we could integrate those shell functions into the dpkg package
> > itself until dpkg is fixed to handle them better. At least, dpkg could
> > replace them with no-op when the proper support is in place.
>
> A fix in dpkg would, IMO, be ideal. I th
Raphael Hertzog <[EMAIL PROTECTED]> writes:
> On Mon, 21 Jan 2008, Joey Hess wrote:
>> The shell functions already have a fairly reasonable interface.
>> rm_conffile mypackage "/etc/pkg/conf.1"
>> prep_mv_conffile mypackage "/etc/pkg_conf.1"
>> mv_conffile "/etc/pkg_conf.1" "/etc/pk
On Mon, Jan 21, 2008 at 01:57:34PM -0500, Joey Hess wrote:
> Moving conffiles is very specific to dpkg, so the code to do it belongs
> in dpkg, then all that's needed is a versioned (pre-)dependency on dpkg.
Well, yes, FWIW I would be perfectly fine with having such snippets in
the dpkg package it
On Mon, 21 Jan 2008, Joey Hess wrote:
> The shell functions already have a fairly reasonable interface.
> rm_conffile mypackage "/etc/pkg/conf.1"
> prep_mv_conffile mypackage "/etc/pkg_conf.1"
> mv_conffile "/etc/pkg_conf.1" "/etc/pkg/conf.1"
> This is not the best possible interf
Michael Biebl wrote:
> Another way would be, to make dpkg smarter about such cases.
> As you want to write a special utility for this, how would you hook this
> up into the install/upgrade process? If you have to edit maintainer
> scripts again, you haven't gained a lot imho.
You've gained not
Stefano Zacchiroli wrote:
> Yeah, but a point is: should we make the snippet in a package and then
> have a dependencies on this? This is going to be suboptimal since some
> of those snippets have to be called in preinst and pre-depends are not
> nice ...
Moving conffiles is very specific to dpkg,
Stephen Gran wrote:
> My concern with this is that it can be important to have the files moved
> in a particular order relative to other things happening in your
> preinst, and a single #DEBHELPER# token might not be flexible. I'm sure
> joeyh will come up with something simple, elegant, flexible
This one time, at band camp, Michael Biebl said:
> Petter Reinholdtsen wrote:
> >[Michael Biebl]
> >>Why do you think, debhelper is not the correct place to handle this?
> >>Imho it would be fairly easy to write a debhelper command for this.
> >>Another way would be, to make dpkg smarter about such
Petter Reinholdtsen wrote:
[Michael Biebl]
Why do you think, debhelper is not the correct place to handle this?
Imho it would be fairly easy to write a debhelper command for this.
Another way would be, to make dpkg smarter about such cases. As you
want to write a special utility for this, how w
On Sun, Jan 20, 2008 at 05:34:53PM -0500, David Nusinow wrote:
> Indeed, the XSF is carrying around tons of shell functions that are
> generally useful and so should go in to some sort of central package, but
> there's nowhere to put them. Getting something like this started has been
> on the backb
On Sun, Jan 20, 2008 at 12:54:42PM -0500, Joey Hess wrote:
> Why are we copying shell functions off of wikis and embedding them into
> our maintainer scripts instead of adding the code to Debian once in a
> utility?
Full ack.
> (I've considered putting this code in debhelper, but the way it's use
On Sun, Jan 20, 2008 at 12:54:42PM -0500, Joey Hess wrote:
> Why are we copying shell functions off of wikis and embedding them into
> our maintainer scripts instead of adding the code to Debian once in a
> utility?
>
> (I've considered putting this code in debhelper, but the way it's used
> is no
[Michael Biebl]
> Why do you think, debhelper is not the correct place to handle this?
> Imho it would be fairly easy to write a debhelper command for this.
> Another way would be, to make dpkg smarter about such cases. As you
> want to write a special utility for this, how would you hook this up
Joey Hess wrote:
Why are we copying shell functions off of wikis and embedding them into
our maintainer scripts instead of adding the code to Debian once in a
utility?
I'm all for this! The sad truth is, that currently a lot of maintainers
simply forget to handle conffiles removals/moves. So h
On Sun, Jan 20, 2008 at 04:44:34PM +0100, Adeodato Simó wrote:
> In summary, `run-parts` is safe wrt .dpkg-bak, `run-parts --lsbsysinit`
> is not.
Easy enough to fix if need be.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Petter Reinholdtsen wrote:
> I just noticed that when I rewrote the conffile removal code in
> initscripts recently, I copied code from
> http://wiki.debian.org/DpkgConffileHandling and accidently replaced
> the code that created *.dpkg-old files with code that would create
> *.dpkg-bak. I will ch
* Roger Leigh [Sun, 20 Jan 2008 15:30:43 +]:
> On Sun, Jan 20, 2008 at 03:10:38PM +0100, Michael Biebl wrote:
> > Regarding run-parts: There is no problem afaik. I quickly tried this:
> > # mkdir test
> > # touch test/foo
> > # touch test/foo.dpkg-old
> > # touch test/foo.dpkg-bak
> > # run-p
On Sun, Jan 20, 2008 at 03:10:38PM +0100, Michael Biebl wrote:
> Roger Leigh wrote:
>> Hi folks,
>>
>> I noticed earlier today that many packages are creating copies of
>> conffiles in their maintainer scripts with the extension ".dpkg-bak",
>> which is not an extension used or removed by dpkg:
>
>
Roger Leigh wrote:
Hi folks,
I noticed earlier today that many packages are creating copies of
conffiles in their maintainer scripts with the extension ".dpkg-bak",
which is not an extension used or removed by dpkg:
Say you name the file /etc/foo.dpkg-old instead of /etc/foo.dpkg-bak.
dpkg won
[Roger Leigh]
> A lot of scripts are copying the rm_conffile script from
> http://wiki.debian.org/DpkgConffileHandling which adds a .dpkg-bak
> suffix to old conffiles.
>
> Are such names allowed? Why can't .dpkg-old be used instead?
I just noticed that when I rewrote the conffile removal code i
Hi folks,
I noticed earlier today that many packages are creating copies of
conffiles in their maintainer scripts with the extension ".dpkg-bak",
which is not an extension used or removed by dpkg:
% grep EXT lib/dpkg.h
#define DEBEXT ".deb"
#define OLDDBEXT "-old"
#define NE
21 matches
Mail list logo
