David Kalnischkies <kalnischkies+deb...@gmail.com> writes:
> Hi Michael Gilbert,
>
> 2010/4/8 Michael Gilbert <michael.s.gilb...@gmail.com>:
>> hi, thanks for looking into this. the two apt-gotted versions need to
>> differ.
>> for example getting kernel source from squeeze, then sid demonstrates the
>> problem.
>
> Ah, now i see. The "problem" is therefore that the versions differ
> not enough - they differ only in the debian revision - not in upstream
> version. (It is normal dpkg-source behavior to only include the upstream
> version number in the unpack-directory.)
>
> I don't think their is a clean and obvious way to cope with this situation:
> The directory with the upstream version number isn't clean - it has the
It might also be dirty because it was already used to compile or even
contain changes made to the package. Reverting it to a clean state might
loose valuable data (as you mention below too). Definetly not good for
the default behaviour.
> changes from the diff applied, so it would be needed to unapply them
> (impossible as we don't know which diff was applied) to apply the new diff.
The version in debian/changelog says what diff was applied. But it might
not exists or be current. The only save way is to delete the directory
and start from scratch. Which dpkg-source already does.
> It could also include local changes so overriding them would be bad
> What would be possible is to reuse the --fix-broken (-f) option here to force
> apt to unpack the source again (all changes will be lost!)
> As it is super simple i have implemented it straight away and
> think this is all we can do about it so i would close it with this feature.
>
> Do you agree?
So "apt-get source foo" says "Skipping unpack of already unpacked source
in foo-1.2" but "apt-get -f source foo" will run "dpkg-source -x
foo_1.2-3.dsc" anyway?
That seems ok to me.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
