On Thursday 23 August 2007 17:26, David Given wrote:
Don Armstrong wrote:
[...]
The people who have responded to you so far strongly suspect that it's
not worth the effort, but without knowing why the glibc we already
distribute can't be used, it's hard for us to give you a definitive
answer.
*nods*
As far as I can tell --- I've contacted upstream to confirm this --- what
plasticfs wants to do is to override the underlying system calls (or at
least, the functions that call them) that access the file system.
Unfortunately, those system calls are not exposed by default, so plasticfs
wants a tweaked glibc in which they are exposed. By overriding the system
calls rather than the higher-level functions, it means that plasticfs
doesn't have to override the higher-level functions --- they work
automatically.
fakeroot and fakechroot appear to operate by overriding *all* glibc
functions that might access the file system. I've had a look at the code...
it's unpleasant. There are a lot of functions that might do this, and not
all of them are easily overridable, and quite a lot of them are rather
obscure. (I'd never even heard of ftw() and nftw() before now.). This makes
it much harder to catch coverage issues. A function that isn't wrapped will
work on the real file system, rather than the virtual one. I notice that
fakechroot doesn't wrap getpwent(), for example --- which means it'll
always use the *real* /etc/passwd, rather than the emulated one. This could
be intentional, but as it's not mentioned in the docs I suspect it's a bug.
I've given up on the replacing-glibc idea; it was pretty horrible anyway.
Unfortunately, the alternatives seem just as horrible, in different ways...
Programmers *always* have idiosyncrasies to deal with, no matter what system
they work on. Windows, Linux, BSD, any *nix, DOS (if you dare). They've all
got problems. Every library in existence has it's own idea of how things
should work. Try using 2 libraries at once -- if they conflict in their
ideas of how things should work, it's a disaster waiting to happen.
Programmers always have, and always will, work around these problems.
glibc makes assumptions about it's underlying implementation -- specifically,
in this case, the system calls. The higher-level functions are specifically
based on these system calls. To modify this is to take the feet out from
under the higher-level functions -- they can't depend on their own
implementation any more. With all due respect, this may work. But it more
probably will introduce a thousand bugs into the higher-level functions.
It also completely blows away a programmer's idiom: implementation privacy.
C++ goes as far as to build this into the language. C doesn't, but it's a
convention that should be adhered to. glibc's developers can -- and probably
will -- change the underlying implementation and the higher-level functions'
implementations to suit it's needs later. The devs feel they have the right
to do this, and, they do. Simple as that. You're swimming with sharks if you
depend on the underlying implementation (even worse if you hack to expose
it).
I would venture to say that this package's upstream maintainers are going at
this with the wrong approach (whatever that approach is). This may be due to
laziness (as is often the case with me :-), or it may be due to lack of time,
or it may be due to lack of information (such as another library or something
that they don't know about yet). Whatever the cause, the source needs to be
fixed to work with the environment given, not vice versa.
That attitude may seem rigorous, but it's really pretty simple: If glibc has
to change for this one package, it's changed for the other 15,000 packages
too. (yes, i know you don't want to install it, but things happen, and having
2 side-by-side copies of glibc is asking for trouble). So, to make one
package work, you broke 15,000 packages. No matter how you run those numbers,
it doesn't make sense -- the one package should change to match the other
15,000.
Disclaimer: This is relatively uninformed conjecture. I haven't looked at the
package's source, any of this implementation, or anything about implementing
filesystems in general. I know about programming in general, and these are
some basic assumptions I make any time I write a program. I don't know the
rationale for the package's development model. So, I really am not trying to
judge anyone. But I'm looking at what I do know with a critical eye, and I
hope you'll do the same.
--
Sincerely,
Jack
[EMAIL PROTECTED]
My GPG Public Key can be found at:
https://www.theanythingbox.com/pgp.htm (top link is current)
I appreciate signatures, but if you only know me online,
please use the --lsign-key, not the --sign-key.
I appreciate trust -- but too much makes it less valuable.
pgplxOhYTv4IU.pgp
Description: PGP signature
