Re: libkpathsea3 -> libkpathsea4 transition?
Hilmar Preusse <hille42@web.de> wrote:
>> 0. wait until libkpathsea4 is in testing (should be only a couple of
>> days)
>>
> Do we have to wait until this is the case? However it doesn't hurt
> if we do.
There shouldn't be much waiting, there seem to be just technical reasons
why it isn't in there yet.
And yes, I think we really should wait. Otherwise we *would*get* a
library transition, because the packages newly depending on libkpathsea4
would have to wait for teTeX, and go in together.
>> 3. When the number of packages still depending on libkpathsea3 is low
>> enough, increase the severity and start NMUing. The problem
>> here is that we can't just check whether the package builds, but
>> instead need to verify that it also does work.
>>
> I still hope most maintainers will take away that job from us.
Knock on wood.
> As
> Olaf suspected the ABI won't, I would not care about it. I'd just
> check if the lib work at all (if the programs in the package find
> any file in the texmf-tree) and I guess we're done then.
There might be problems because the names changed - e.g. in
libkpathsea3, "--format=map" would find files in TEXMF/fontname, which
are now in TEXMF/fonts/map/fontname, whereas in libkpathsea4 the format
refers to all map files, which previously were found with
"--format='dvips config'".
>> The final goal should be to have no packages depending on
>> libkpathsea3 in etch, and to drop it completely in etch+1.
>>
> Can't that be dropped for etch?
I think it's usual to keep old libs one release after they are no longer
used by Debian packages.
Regards, Frank
--
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)
Reply to: