Depending on external libraries

[Daniel Stone]

--bFLMNMO8U1IqPzi2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Mar 13, 2004 at 01:44:09PM +0100, Egbert Eich wrote:
> Daniel Stone writes:
>  > 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 w=
as
>  > for Debian, which, as you know, is very much 4.3.
>=20
> Right. Unfortunately.

It is, at least, 4.3 plus lots and lots of patches; about halfway to
4.4.

>  > > Just to state it again: most libs in extra/ are indeed external depe=
ndencies.
>  > > They are maintained outside of this project and used in different co=
ntexts.
>  >=20
>  > 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.
>=20
> 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.

I think 'maintained' rather than 'developed' is a more accurate picture
here.

>  > 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.
>=20
> That's why we have version control systems that keep track of the changes
> and offer to log a comment on the changes.

Right, but they still don't buy you instant familiarity with the code in
question; you may not remember why you did something, or understand the
code without taking a deep look.

>  > 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
>=20
> 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 produ=
ct.

=2E.. Debian ... not quite five years, but still.

>  > 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, a=
nd
>  > more likely to help. It also makes co-ordinating security fixes several
>  > zillion times easier, as demonstrated by the zlib fiasco.
>  >=20
>  > Also, I understand the whole backporting thing - I'm a Debian Develope=
r,
>  > remember.
>=20
> 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?

It depends; we work out what they really need, not wat they think they
need. If they need a bugfix, it gets backported and released into woody.
If they need a trivial feature, it gets backported and released as an
'unofficial' backport. If they need more stuff than it's worth, we just
backport the new version. If that means dragging back newer versions of
other packages, so be it.

>  > 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?
>=20
> 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=20
> just released.

Stable is irrelevant to desktops; hell, I run sid on half of my
production servers. I'll engage you on this point in private if you
like, but it's OT for this list.

>  > > Code that has been there since 1997 and used since then may not be b=
ug 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 issue=
s,
>  > > though.
>  >=20
>  > 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, su=
id
>  > root binary under our control. Oh, it also listens on the network.
>=20
> 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.

No, it just means that no-one's hit it with the right set of conditions,
really.

--=20
Daniel Stone                                            <daniel@freedesktop=
.org>
freedesktop.org: powering your desktop                http://www.freedeskto=
p.org

--bFLMNMO8U1IqPzi2
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAVAr2cPClnTztfv0RAt5QAJ9G+JqWl95/2VIAlCfjZqyCDVetnQCgjNqs
1FMH0iANSzmLUJJ5VPibE0c=
=eqRf
-----END PGP SIGNATURE-----

--bFLMNMO8U1IqPzi2--