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 jakykong@theanythingbox.com 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.
Attachment:
pgptJW6yDTtlW.pgp
Description: PGP signature