Stefano Zacchiroli <firstname.lastname@example.org> writes:
> On Mon, Mar 24, 2014 at 04:58:22PM -0700, Russ Allbery wrote:
>> If one of our upstreams said that they wanted to rename a public API in
>> a widely-used shared library because they thought the old name wasn't
>> very accurate, we would almost certainly beg them not to, due to all of
>> the pain this would cause for marginal benefit. I encourage people to
>> think of the archive URLs in the same light. If anything, the pain is
>> even worse.
> Just a side comment on this: your reasoning here is valid for full blown
> API renames, because they break backward compatibility. But the
> reasoning does not apply to: add a new public API, document it, preserve
> backward compatibility for the old API, drop the documentation for the
> old API --- in your analogy, it is this second option the closest to my
> (very) long term evil plan behind non-free.org.
I think the analogy holds, though. With a shared library, you don't drop
the old API until you have to do an ABI break for other reasons, which
means that old binaries won't work against the new library anyway. At
that point, you have a pretty clean break point where, provided people
have addressed deprecation warnings, you lose nothing by dropping the old
For our archives, there is no such thing as an ABI break (or at least
hopefully there won't be), so there is no point at which doing this would
stop being painful.
It's similar to dropping an interface from libc6. The right thing to do
is just never do that, unless there's something so serious and so
problematic you don't have any other choice.
> You will probably disagree that there is value in such an exercise,
> which is merely at the communication level, and which had never even
> been really promoted (yet). But this second criticism is definitely not
> in the realm of inflicting pain to existing users.
I understand that inflicting pain isn't the goal, but that's what this
actually does, whether intended or not. You have to go change
sources.list on a bunch of systems, redo mirroring, find and change all
your documentation, and so on. Plus, many of us have internal archives
that parallel the same main/contrib/non-free setup for much the same
reason, so now it's harder to explain to users how that works since we can
no longer parallel what Debian is doing unless we set up completely
separate repository hosts, for no particularly good technical reason.
Russ Allbery (email@example.com) <http://www.eyrie.org/~eagle/>