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

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
    if test -x /usr/bin/perl; then
      echo "#!/bin/perl" > $PERLSCRIPT
  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
#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: