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
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
