On Tue, 23 Aug 2011, Sven Joachim wrote:
> > Yes, that doesn't matter at all for the purpose of this test at least.
>
> I've only made test-conffile-link0 a conffile and test-conffile-link1 a
> hardlink to it.
The problem with this is that you don't know which copy will become
the main file in th
On 2011-08-23 15:10 +0200, Raphael Hertzog wrote:
> On Mon, 22 Aug 2011, Sven Joachim wrote:
>> Thanks, this was very helpful indeed. After reading that, the only
>> pitfall I fell in was that git does not preserve hardlinks, so I needed
>> to handle that in build-hook/clean-hook targets.
>
> Rig
On Mon, 22 Aug 2011, Sven Joachim wrote:
> Thanks, this was very helpful indeed. After reading that, the only
> pitfall I fell in was that git does not preserve hardlinks, so I needed
> to handle that in build-hook/clean-hook targets.
Right, I just noticed/remembered that we have t-unpack-hardlin
On 2011-08-21 22:12 +0200, Raphael Hertzog wrote:
> On Sun, 21 Aug 2011, Sven Joachim wrote:
>> > Can you also turn your testcase in a patch against pkg-tests.git?
>>
>> Once I have acquainted myself with the testsuite, probably yes. Might
>> take a few days, I have other things to to as well.
>
On Sun, 21 Aug 2011, Sven Joachim wrote:
> > Can you also turn your testcase in a patch against pkg-tests.git?
>
> Once I have acquainted myself with the testsuite, probably yes. Might
> take a few days, I have other things to to as well.
You might find
http://wiki.debian.org/Teams/Dpkg/Contribu
On 2011-08-21 11:04 +0200, Raphael Hertzog wrote:
> The problem is that the hardlinking code is not aware that the target
> file is still in .dpkg-new and not yet in its final location. This is
> because conffile are not processed like normal files and thus do not
> inherit the usual fnnf_deferred
Raphaël, your patch solves the problem,
al least I can't reproduce it any more.
Tried many times, conffiles are treated as expected.
Thanks!
Sven, also thanks for your corrections.
2011/8/20 Sven Joachim
> The reason is that conffile processing takes place after
> unpacking all non-conffiles, so for hardlinks to conffiles you hit the
> ENOENT bug. If a file is both a conffile and a hardlink in the package,
> it is treated as the latter.
>
Do I understand it right?
When in
tag 638291 + patch
thanks
On Sat, 20 Aug 2011, Sven Joachim wrote:
> It's not clear to me what the contents of the old version and the
> situation on the filesystem were, but this is reproducible even on fresh
> install. The reason is that conffile processing takes place after
> unpacking all non
On 2011-08-18 13:06 +0200, Igor Pashev wrote:
> Package: dpkg
> Version: 1.16.0.3
> Severity: normal
>
> By default all files in /etc are considered as config files and to be kept on
> package upgrade (or ask to user what to do with new config file).
Those which are shipped in packages as conffil
Package: dpkg
Version: 1.16.0.3
Severity: normal
By default all files in /etc are considered as config files and to be kept on
package upgrade (or ask to user what to do with new config file).
This works excelent for regular files, but can fail if there are two or more
hardlinks to the same file,
11 matches
Mail list logo
