[Fedora-packaging] Re: Request to drop %(%{__id_u} -n) in preferred buildroot

[Ralf Corsepius]

On Wed, 2006-07-19 at 21:02 +0200, Axel Thimm wrote:
> On Wed, Jul 19, 2006 at 02:29:27PM +0200, Axel Thimm wrote:
> > Also consider what this really is about: Deambiguifying the
> > BuildRoot per package makes sense as there may be several build
> > processes sharing the same filesystem (either locally or through
> > NFS), but deambiguifying the build user, too, means that we assume
> > that the same EVR package will be possibly built on the same
> > filesystem by different users? And even simultaneously?
> 
> On Wed, Jul 19, 2006 at 04:46:56PM +0200, Ralf Corsepius wrote:
> > On Wed, 2006-07-19 at 16:15 +0200, Axel Thimm wrote:
> > > On Wed, Jul 19, 2006 at 08:54:22AM -0500, Rex Dieter wrote:
> > > > Axel Thimm wrote:
> > 
> > > > > Two independent reviewer considered this a blocker for a 
> > > > > review's acceptance (even though it's marked "preferred").
> > > > 
> > > > The reviewers need to be whacked with a clue-stick.  A working (non-broken)
> > > > buildroot is *not* a blocker.
> 
> > The point you  seem to be missing, your buildroot is broken:
> > buildroot: %{_tmppath}/%{name}-%{version}-%{release}-root
> 
> No, I'm not, I added the original post above to prove I was aware of
> that ;)
> 
> > This directory is NOT unique and will break if 2 or more users are
> > running an rpmbuild in parallel on the same /var/tmp filesystem.
> 
> And everything will break if someone builds for i686 and i586 (e.g. a
> kernel or glibc) simultaneously on the same filesystem (as the same
> user),
True, i.e. defect/bug.

> > It will also break if 2 different users are running buildjobs of the
> > same package consecutively and if the first one fails and leaves it
> > buildroot behind.
> 
> That's what rm -fr %{buildroot} at the beginning of %install is
> for.
Nope, these buildroots will carry different uids 
=> User2 cannot remove user1's buildroot.

Let me demonstrate it with one of your rpms:

# su -l user1
# rpmbuild -bi vtkdata.spec
# exit

# su -l user2
# rpmbuild -bb vtkdata.spec
...
+ rm -rf /var/tmp/vtkdata-5.0.1-4-root
rm: cannot remove `/var/tmp/vtkdata-5.0.1-4-root/usr/share/vtkdata-5.0.1/Data/cth.vtr': Permission denied
rm: cannot remove `/var/tmp/vtkdata-5.0.1-4-root/usr/share/vtkdata-5.0.1/Data/Particles.raw': Permission denied
...

With FE's current buildroot this case doesn't happen.

> I'm just saying that we are focusing on an almost non-existant corner
> case obfuscating the BuildRoot while we allow failures in non-corner
> cases.
I don't see how working in a multiuser environment would qualify as a
corner case. Building for different target archs to me is a corner case,
but that's probably a matter of personal background.

The above situation above would easily happen if working in a team, e.g.
when developing an rpm.spec.

Ralf