Re: Some ideas and concerns regarding fakeroot
> joost witteveen wrote:
>
> > I like the idea. There's one thing I'm not sure about, though: stat().
> >
> > Suppose we've got two packages, foo and bar. One does, in the make install:
> >
> > if test -f /etc/foo-info; then
> > process /ect/foo-info, do things with info,
> > and install the foo accordingly;
> > else
> > echo /etc/foo-info missing. Please create this file and re-run make info.
> > fi
>
> This package is examining the system on which it is _compiled_ to make
> decisions about the system on which it is _run_. That's fine when
> they are the same system, but it causes problems for Debian packages.
>
> Namely, people who want to recompile the package will have to
> duplicate the maintainer's system exactly, possibly including the
> mysterious contents of /etc/foo-info.
>
> I think that all such decisions about what to install should be
> overridden by the debian/rules file, and should in no way depend
> on what happens to live in /etc on the maintainer's system.
So, you think
stat(file living in /, but not in VIRTUAL_ROOT/)
should return "no such file or dir" (as we like for package "bar").
Well, OK, I'll change the foo example:
if test -x /bin/perl; then
echo "#!/bin/perl" > $PERLSCRIPT
else
if test -x /usr/bin/perl; then
echo "#!/bin/perl" > $PERLSCRIPT
fi
fi
echo 'U(NF($&*#@K$UP(@)(FN@(#*nf83498O*#U<<(0834.>>??u980r4>' >>$PERLSCRIPT
Now, do you still want stat(file living in /, but not in VIRTUAL_ROOT/)
to always return "no such file or dir"?
> Therefore, if fakeroot "breaks" such examination code by returning
> information from the empty VIRTUAL_ROOT system, it serves as a nice
> big warning sign to the package maintainer.
Sure, we can say that packages that test where perl resides
at "make install" time (they ought to do it at "make build" time)
are broken. But the idea was to simplify package creation.
My fear is that, when stat() cannot be trusted any more, we
may break many packages.
OK, I cannot come up with any packages that will break now. But
the point is, programming fakeroot is a bit tricky[1]. It alread was
when all it had to do was some very simple, well defined things.
But I really do fear it becomes _very_ tricky when I can (without
even starting to write any code, but just by having lunch) think
of (admitted, strange) examples where it's for humans difficult to
say what fakeroot[2] should do.
[1] As exmplained in the manual page, I've written quite a few
both much larger and much smaller programmes than fakeroot.
But when it comes to the ability of a programme to hide it's
bugs from both it's users and it's creator, fakeroot really
is unparallelled. For example, fakeroot-0.0-3 _looked_ like
having no bugs, it could compile itself, and simple commandline
tests revealed nothing. Untill you start creating&deleting inodes
on the same machine, outside fakeroot. Or you interrupt fakeroot.
Or... There were so many bugs in fakeroot-0.0-3...
[2] OK, I could just go ahead and implement the suggestions Christoph
made. It doesn't look all that complicated.
--
joost witteveen, joostje@debian.org
#!/usr/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
#what's this? see http://www.dcs.ex.ac.uk/~aba/rsa/
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: