Control: notfound -1 1.17.27
Control: tags -1 - unreproducible moreinfo
On 2016-06-05 00:49 +0200, Guillem Jover wrote:
> Control: severity -1 important
> Control: tags -1 unreproducible moreinfo
>
> Hi!
>
> On Sat, 2016-06-04 at 17:43:41 +0100, Adam D. Barratt wrote:
>> Control: reassign -1 dpkg-dev 1.17.27
>> Control: affects -1 devscripts
>> Control: retitle -1 dpkg-source -x overwrites existing directories
>>
>> On Sat, 2016-06-04 at 18:08 +0200, ydir...@free.fr wrote:
>> > dget unpacks the downloaded source by default, even if the target
>> > directory was
>> > pre-existing. Moreover, it does not just unpack it above the pre-existing
>> > dir,
>> > but removes it first, together with all the other files it may contain !
>>
>> Nope. dget simply calls "dpkg-source -x". The effect is trivially
>> reproducible by calling "dpkg-source -x somepackage.dsc
>> an-existing-directory" without needing to involve dget at all.
>
> Hmm, I'm afraid I cannot reproduce this on stable nor unstable. I've
> tried with devscripts, fbset, dpkg-repack and dgit, to try different
> source formats:
>
> $ dpkg-source -x devscripts_2.16.4.dsc new-dir
> dpkg-source: info: extracting devscripts in new-dir
> dpkg-source: info: unpacking devscripts_2.16.4.tar.xz
> $ dpkg-source -x devscripts_2.16.4.dsc new-dir
> dpkg-source: error: unpack target exists: new-dir
>
> I'd appreciate if any of you could provide a reproducer for this?
As Adam had already mentioned: omit the new-dir argument, then
dpkg-source -x will happily rm -rf the directory into which the source
package is unpacked. This behavior has been present "forever" (well,
the oldest version I could test is dpkg-dev 1.6.15 from potato).
Cheers,
Sven
