[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#391240: debian-policy: Please elaborate on cleaning up files outside the build dir



Bill Allombert <allomber@math.u-bordeaux.fr> wrote:

> On Thu, Oct 05, 2006 at 06:58:48PM +0200, Frank Küster wrote:
>> Therefore, I suggest the following patch to the Debian policy:
>> 
>> --- debian-policy-3.7.2.2/policy.sgml.orig	2006-10-05 18:52:02.000000000 +0200
>> +++ debian-policy-3.7.2.2/policy.sgml	2006-10-05 18:58:19.000000000 +0200
>> @@ -1882,7 +1882,15 @@
>>  		and <tt>binary</tt> targets may have had, except
>>  		that it should leave alone any output files created in
>>  		the parent directory by a run of a <tt>binary</tt>
>> -		target.
>> +		target<footnote>
>> +		  This includes files that are generated outside the
>> +		build directory, e.g. dotfiles in $HOME (if that
>> +		exists) or TeX font cache data.  Note that TeX is
>> +		often called indirectly to create PDF or PS versions
>> +		of documentation.  Hints for cleaning up the TeX font
>> +		cache are in the TeX policy draft in
>> +		the <package>tex-common</package>  package.
>> +		</footnote>.
>>  	      </p>
>
> This kind of requirement does not seem realistic in general.
> It would be simpler and better to require that the build 
> process do not write outside the build directory and /tmp.
> (This might require change to building tools that does not
> allow to set their state directories) This would avoid
> the risk of removing user dotfiles by mistake or missing
> to remove some files. 

Yes, my wording is not optimal.  We should not mandate how a package or
its build-depends achieve that goal, and not creating files in $HOME at
all is certainly best.  Maybe we should write

+ Packages should take care not to create files outside the build
+ directory, e.g. dotfiles in $HOME (if that exists) or TeX font
+ cache data, and to remove those files if they were created below
+ the build directory instead.  Note that TeX is often called
+ indirectly to create PDF or PS versions of documentation.  Hints
+ for cleaning up the TeX font cache are in the TeX policy draft in
+ the <package>tex-common</package> package.

> This would also failuer when build by
> a buildd where the buildd user does not have a home directory.

That's a different issue - I've already encountered one build failure
because of this (IIRC it was fontforge that insisted to segfault if it
couldn't write to $HOME).  I think the place to document this is either
the third paragraph of 4.9, after talking about interactive
configuration scripts, or the first paragraph after the following list
of targets, which currently only specifies: "The build, binary and clean
targets must be invoked with the current directory being the package's
top-level directory."

> For the TeX problem, I would suggest to add a local texmf.cnf
> file that setup the font cache in the build directory. This
> way it is easy to clean up in clean target. 

Setting the environment variable TEXMFVAR to $(CURDIR)/.texmf-var does
it as well.  But the point is that, just as with dotfiles, this is
something the package has to do in its rules file, because no utility
can guess that it's being called by a package build process.

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)



Reply to: