Ben Collins-Sussman <firstname.lastname@example.org> writes:
> Okay, so maxb's analysis is that David Summers' svn 1.1 RPMS were
> statically linking against BDB 4.0, but the user's previous 1.0.9 RPMs
> (whereever they came from) were statically linking against BDB 4.2...
> This makes me ponder two different things:
> 1. Maybe package maintainers should clearly label (or even warn) which
> version of of BDB they're using, since changing BDB versions can so
> easily wreak havoc on unsuspecting users?
That would probably help.
> 2. a separate question -- and this is nothing against David or any
> other packager -- I wonder if our downloads page shouldn't make it
> really, really clear that
> A. the Subversion project only "officially" tests and releases
> B. every link we provide is to volunteer-produced packages.
> This is on my mind lately, because whenever someone has a problem with
> a binary package (for any OS) the first thing they say is, "but I'm
> using the official package from the Subversion site!" There's this
> common misunderstanding that keeps coming up. A lot of users think
> that if they follow and install those links, then nothing can possibly
> go wrong because they've all been thoroughly tested and blessed. We
> need to make it clear that we're providing those links merely as a
> convenience, don't you think?
At first, I thought this sounded like a good idea. But the more I
thought about it, the less comfortable I became.
The Subversion project as a whole has been benefiting from David's and
other packager's work. Why should we suddenly pretend we're strangers
when the occasional problem crops up?
"What, RPMs? Never heard of 'em. Some sort of packaging system,
is it? Well, we've got nothing to do with it..."
I'm being facetious, of course :-), but only partly.
With or without the proposed disclaimer, we're not going to behave any
differently. When people come into our lists and IRC channels with a
problem, we're going to try and help them. If we loudly proclaim that
these packages aren't "blessed", what will that really mean? What
will it gain anyone? People will still download them, still use them,
and when they have problems, they'll still come to the same place.
So let's just try to do a better job of labeling the packages and
their potential incompatibilities, and when there are problems, we
take our lumps and try to solve them.
If some package maintainer were to produce consistently unreliable or
gratuitously incompatible packages, then we should stop linking to
those packages. But so far, that hasn't happened. It certainly
didn't happen in this case; all we really have here is a labeling
problem, albeit one that bites pretty hard :-).
David, would you like to take care of committing the appropriate
language to the web pages? You know best what needs to be said
regarding upgrades & incompatibilities.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sat Nov 27 05:28:54 2004