Re: libc6 dependency generation
> > > > But that still leaves the question: Why is a change from 2.2.5-4
> > > > to 2.2.5-13 changing the symbol set? I would have expected that
> > > > the upstream "libc6" group would not do that on minor revision
> > > > changes (i.e. 2.2.4 to 2.2.5). Surely there is some upstream
> > > > libc6 policy they follow that says, for example:
>
> > > Please don't guess things like that.
>
> > I'm a software programmer of considerable experience (20+ years). I
> > believe I have the ability to make educated guesses as to the design
> > of various software projects. Taking a few moments to do also means
> > that I learn better as people explain the way things really are and
> > why they are that way. You should never discourage someone from
> > taking initiative when it comes to learning and thinking on their
> > own; they are essential skills in programming as well as life in
> > general.
>
> I'm asking you to phrase the thought differently. "Surely there
> is..." leaves the impression that one would be stupid for consdering
> doing it another way. But system libraries rarely behave in sane or
> expected ways. =)
There are many other ways, but I see no other "good ways". Any large
project needs to have some sort of methodology to its naming/numbering.
And, since I hold people who can comprehend and manage a project of such
complexity as glibc/libc6 is such high esteem, I was quite sure that they
had done such. It has been confirmed that the glibc group does have
such a policy, though it is not the same as my example.
> > > Glibc has alot of linker magic in it to permit them to fix things.
> > > For example, they may restrict the ability of new programs to link
> > > to a symbol but still allow old programs to call it. They may
> > > introduce some extra functionality in a call, but permit older
> > > programs to still run correctly.
>
> > Just because it can does not mean it should. I'm not saying "it
> > should not", and never have.
>
> Again, the phrasing you gave certainly left that impression.
I try to be careful about what I say in email as it is usually read much
harsher than it was written. Plus, I think almost everybody (and this
definitely includes me :-) takes question about their design as being
an implication that it's "wrong" or "broken". I appologise if that's
the impression I gave as it wasn't my intention.
> > However, "linker magic in it to permit them to fix things" sounds a
> > lot like "we can get away with bad decisions because the linker will
> > hide them".
>
> That's exactly what it is, though - Bad decisions made in the past can
> be corrected without requiring everyone to recompile. And further,
> new archs or OSs that glibc is ported to don't have carry around the
> baggage.
And that's an excellent feature of the linker. I don't think anybody
gets their design right the first try. It's an evolving thing.
> > Does libc6 have any desire to be "forward compatible" with programs
> > linked against a version later than the one currently installed?
> > Such would allow things like including a single package from a later
> > Debian distribution without the need to upgrade the base system.
>
> To the extent that they'd like to be bug free, sure. =) Aside from
> that, I don't think so. Ben's got more history with glibc than I do,
> so he might be able to provide more details.
"Forward compatibility" is one of those "nice to have" things. It's not
worth sacrificing for, though. Nor is it worth considerable development
effort, at least in my opinion.
> My sig line seems particularily appropraite to this thread...
I noted that and got a simle out of it.
> --
> learning from failures is nice in theory...
> but in practice, it sucks :)
> - Wolfgang Jaehrling
Brian
( bcwhite@precidia.com )
-------------------------------------------------------------------------------
Sticks and stones may break bones, but words will shatter the soul.
Reply to: