Re: debian/rules clean as root or non-root?
Jan Hauke Rahm <firstname.lastname@example.org> writes:
> On Thu, Feb 11, 2010 at 07:42:37AM +0100, Goswin von Brederlow wrote:
>> Sven Joachim <email@example.com> writes:
>> > On 2010-02-10 21:37 +0100, Goswin von Brederlow wrote:
>> >> Sven Joachim <firstname.lastname@example.org> 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.
> Well, then do so. :)
>> 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.
> It would catch those cases, BUT working on files that don't belong to
> you can always lead to weird behavior, especially if you have a mix of
> files owned by you and others. This is not packaging related but an
> issue with your rights management (and workflow maybe). I don't think it
> makes sense to solve it in debian/rules anyhow.
>> >> 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.
> debian/rules clean should provide you with exactly the same you had
> after unpacking. If the files didn't belong to you then, they don't
> belong to you now. There is nothing to catch here. Work in your own
> $HOME :)
But it doesn't. It fails to delete some files and the error is ignored.
Then on build old files will be used or, with luck, the build fails in