[Fedora-packaging] Refining today's "don't touch system fs" guideline

[Ralf Corsepius]

On Thu, 2006-10-12 at 20:20 +0200, Axel Thimm wrote:
> We voted today on
> 
>   "Build scripts of packages (%prep, %build, %install and %check) may
>    only alter files (create, modify, delete) under %{buildroot},
>    %{_builddir} and valid temporary locations like /tmp, /var/tmp (or
>    $TMPDIR or %{_tmppath} as set by the rpmbuild process).
> 
>   Further clarification: That should hold true irrespective of the
>   builder's uid"
> 
> But after thinking about it I'm not quite happy now. Since we go into
> details naming what the build scripts are, we should make clear
> that they are not equal in what they may or may not do. For example
> %{buildroot} should only be modified by %install, not %prep/%build and
> %check.
Though I agree that the formulation could have been better, I do not
agree upon your conclusion.

Remember, the intent behind all this was to say: "building an rpm must
be free of side-effects on the hosting system.". We had tried to narrow
this to file system operations ("alter files") to make this more
understandable/handy to "Joe Occasional Builder".

I don't think we should try to further narrow this to "what to do when,
and when is rpm allowed to do what". IMO, this is a completely different
question and beyond the scope of the problem we had wanted to address.

> How about extending the rule and having a root/non-root rule, too,
> e.g.
> 
> o Package builds should yield the same results irrespective of the
>   packaging process' uid/gid, for example builds under root and
>   non-root users should behave the same.
> 
> o Build scripts of packages (%prep, %build, %install and %check) may
>   only alter files (create, modify, delete) under %{buildroot},
>   %{_builddir} and valid temporary locations like /tmp, /var/tmp (or
>   $TMPDIR or %{_tmppath} as set by the rpmbuild process).
>   %{buildroot} should only be allowed to be altered in %install
>   scripts.
Technically, in some (rare) occasions, this last sentence is not
applicable.

 E.g. there exist packages, which want/need to be built "multi-staged",
with %build containing (often: temporary) installs to %{buildroot}.
In some (very rare) occasions, packages even require "building" inside
of %buildroot.

 The constraint you're adding above, would (IMO: unnecessarily) close
out these packages from being packaged, or force packagers to resort to
move "building" to %install.

Ralf