Bug#354507: libkpathsea3 should be removed

[Frank Küster <frank@debian.org>]

Hello Adrian,

Having thought about this, I come to the conclusion that you are right
(with some small caveat, see below).  But I'd like to tell you why it
took me so long, and caused a sometimes emotional discussion.

When you submitted the bug and subsequently were told that there were
already plans how to do it, I had hoped that you would read the old
threads in the archive (or ask for pointers).  If you'd have told us
"I've read <link>, but I think the same can be achieved much
easier:...", I would have been much more open to your suggestions.

The way it was, we were discussing each point bit by bit, and I had the
impression that you didn't think about *all* the consequences of your
proposal, but instead just wanted to push your idea.  Probably that
impression was wrong, but still I had it.


So okay, I think that we might get rid of libkpathsea3 faster if we
rename libkpathsea4-dev to libkpathsea-dev, and request binary NMUs if
needed.  But there's one thing left I'm not sure about:

If the tetex-bin source package provides a libkpathsea-dev binary
package, doesn't that mean that the libkpathsea3 source package, which
provides the same binary package, must disappear from the respecitve
distribution? 

If that's true, tetex-bin wouldn't be able to enter testing until all
packages that depend on the libkpathsea3 binary package have switched to
libkpathsea4, *and* entered testing.  Since there might be other,
unrelated RC bugs in them, this would be a problem for tetex-bin.

If I'm not mistaken with this analysis, we would additionally have to do
a reupload of the libkpathsea3 source package, renaming the development
package to libkpathsea3-dev.  No, that wouldn't even work, since it
couldn't [1] migrate to testing before all packages that Build-Depend on
libkpathsea-dev have switched to libkpathsea4-dev (or libkpathsea3-dev,
for that matter).

I'm quite sure that you again have a clever solution for that (earnest,
since you have thought a lot about the disadvantages of testing
migration and probably about how to circumvent them), but I'm at a loss
currently. 

Regards, Frank



Footnotes: 

[1] I don't know whether the testing scripts actually check for
satisfied Build-Dependencies, but I think we shouldn't deliberately
break them.

-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)