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

Re: Package requiring a customised version of libc6

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 

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 

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.


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: pgpDwv2jwhj4X.pgp
Description: PGP signature

Reply to: