Depending on external libraries

[Egbert Eich]

Daniel Stone writes:
 > > 
 > > I'm not denying this. However I'd like to suggest to define a canonical
 > > set of X pieces that we are hosting on fd.o.
 > 
 > Err, what do you mean? Do you mean my recent blog entry[0]?

I have no idea what you mean by 'blog entry[0]'.
 > 
 > >  > > This argument however gets partly invalidated when versions of
 > >  > > libs get released that depend on prerelease version of other libs.
 > >  > 
 > >  > ... so don't do that.
 > > 
 > > Please don't tell me, tell those who do.
 > 
 > Bludgeoning upstreams isn't some divine privilege only I have: everyone
 > can do it! ;)

I was merely mentioning that people are invalidating the causes they
state themsleves. You where suggesting I should not do this. Well
so far I did neither.

 > 
 > Sorry, I hadn't checked recently - and haven't really checked out a
 > monolithic 4.4 tree, ever. The last time I was doing monolithic work was
 > for Debian, which, as you know, is very much 4.3.

Right. Unfortunately.

 > 
 > > Just to state it again: most libs in extra/ are indeed external dependencies.
 > > They are maintained outside of this project and used in different contexts.
 > 
 > Yes, but the thing is, these are forked codebases - the build system
 > differs, often the code differs, there are release schedule issues, et
 > al. No matter what the intent, the reality is that forked versions are
 > being maintained.

A fork is something where the code gets developed independently.
These are just 'drop in' sourcetrees. The build system differs,
yes, that's the only painful thing from a release engineer's point
of view.

 > 
 > Yes, but if I was maintaining a library, and someone asked me about a
 > bit of code in my last release, I'd likely be able to give them an
 > answer very quickly, probably off the top of my head. OTOH, if someone
 > asks me a question about code that's changed 17 times since 1998, where
 > the code dates from, I'm far less likely to remember and/or be useful.

That's why we have version control systems that keep track of the changes
and offer to log a comment on the changes.

 > 
 > So, to me, while the new version will certainly have newer, different,
 > bugs, I'm far more comfortable with that. It will be getting exposure in

You wouldn't be if you were working for a company that offers at least
five year maintenance and support to their business customers for a product.

 > the world outside of X (Expat, for instance, is used far more widely
 > than just in X), the developers will be more familiar with the code, and
 > more likely to help. It also makes co-ordinating security fixes several
 > zillion times easier, as demonstrated by the zlib fiasco.
 > 
 > Also, I understand the whole backporting thing - I'm a Debian Developer,
 > remember.

Right. So what do you do if someone needs a new version of package
foo for a debian 'woody'? deliver everything that package depends on
in a newer version or try to keep package foo as self contained as
possible?

 > 
 > >  > I don't think external-dep problems are harder to track down: on the
 > >  > contrary, the newer versions are always more widely deployed, and
 > > 
 > > I doubt this.
 > 
 > Which versions of Expat are distributions shipping as their common-use
 > lib for everything to link to? The newest upstream version, or some
 > random forked X version?

You said 'the newer versions are more widely deployed'. The now old
version was new once, too. At that time it was widely deployed. From
this we obtained some knowledge about the problems with this piece
of software. Look at debian: You declare a version 'stable' only after
it has been given extensive 'soak time'.
Therefore the version debian stable is shipping isn't the one you have 
just released.

 > 
 > By distributions, I mean Linux distributions, the BSDs, OS X, Solaris,
 > everyone.
 > 
 > >  > they're a known quantity to upstream, not some random fork they haven't
 > >  > looked at the base of since 1997. Upstreams are also usually more
 > >  > willing to provide support and/or fixes for problems that occur in newer
 > >  > code.
 > > 
 > > Code that has been there since 1997 and used since then may not be bug free
 > > but one can be pretty certain that the bugs that have not been found will
 > > not bother anybody. This may not be entirely true for security issues,
 > > though.
 > 
 > Bugs always bother people - it's just a matter of how much. I also don't
 > think we can afford to have anything but a proactive approach to
 > security, especially given we have a massive, very-widely-deployed, suid
 > root binary under our control. Oh, it also listens on the network.
 > 

bugs that have been detected but not fixed bother people. Bugs that
never become relevant are no concern. A software that has been around
for a long time in 'bug fix mode' is not necessary 'bug free'. But
the remaining bugs have never surfaced therefore they may not have
practical relevance.

Egbert.