Sven Joachim <svenj...@gmx.de> writes:
> On 2010-02-10 21:37 +0100, Goswin von Brederlow wrote:
>
>> Sven Joachim <svenj...@gmx.de> writes:
>>
>>> On 2010-02-10 19:02 +0100, Goswin von Brederlow wrote:
>>>
>>>> I often see sources where debian/rules clean aborts claiming it needs to
>>>> be run as root. So then I run it with fakeroot. But if the source was
>>>> previously build as root then running fakeroot debian/rules clean might
>>>> not be enough. I think the existing dh_testroot helper is insufficient
>>>> and anoying for the job.
>>>
>>> It is both insufficient and unnecessary, I don't use it in my packages.
>>> Neither does "dh clean", BTW.
>>
>> If you build the package as real root and it creates a new directory
>> (like installing into debian/package/ always does) then you can not
>> clean without being real root. So the check isn't unnecessary.
>
> Yes, and dh_clean will almost certainly fail in such a situation.
> Unless, maybe, you went to the insanity of running the build target with
> real root rights.
That is usualy what happens. Haven't yet completly tought my coworkers
to always build packages as user.
The extended dh_testroot I suggested would also catch cases where the
package was build by another user I think. Might need some tuning (chmod
770?) to allow building by multiple users in a common group and setgid
bit set.
>> If you did run only debian/rules build as root the error might
>> get ignored and lost in the output.
>
> Why would anyone want to run the build target as root? If you do that,
> even running the clean target as root might not give you a state where
> you can build the package as a normal user again.
>
> Sven
It happens. The important part would be to clearly catch such a case. I
can then delete the working dir and unpack the source again or check it
out again.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
