Hi, I realize TeX is tough program to maintain. Thanks to Frank. One quick and easy way to avoid TeX related build issues are to avoid using TeX related tools during build time. So the results will be Debian only ships documentations in plain text and HTML. (No PS and no PDF). But is it what we should do? On Sat, Dec 17, 2005 at 01:38:25PM +1000, Anthony Towns wrote: > On Fri, Dec 16, 2005 at 11:24:39AM +0100, Frank Küster wrote: ... > > It's been in experimental for more than half a year. > > Err, that's kind of absurdly long too. But I din not use it then :-( ... > Six months is a lot of time; and experimental should provide you with > the space and machine power to handle the rebuilding. Yes and no. Rebuilding "Debian Reference" takes few hours on 2GHz machine. So it is not easy but possible with 6 months. But tracking down cause of failure is not that simple. tetex-base has over 70MB as installed (bigger than kernel source.) So it is quite time consuming and close to impossible for non-tex expert. > I don't know how > many source changes are necessary to do the rebuilding, though. The changes may be few strings but ... where? > > So either we could have delayed teTeX 3.0 until > > god-knows-when, > > Uh, no. The whole point is to delay _less_, not more. Yes. Many document build scripts implement some special case fix thus it will break with upgrades. Also new major upgrade tends to pull in minor bugs into huge tetex package. Thus these will cause FTBFS (RC) bugs on many documentation packages whose maintainers are not always ready for making complicated adjustment to TeX upgrades. Recent changes to TeTeX 3 was easier than woody days. For example, when I got FTBFS RC bug due to tetex, I reassigned it to tetex. I should have reduced severity but I did not do it partly because of my wish to get Frank's attention and his assistance to fix it from Tetex package. Sorry. This may be the reason Frank felt about FTBFS/RC. It is not FTBFS for him and that was not RC for him. I wish that tetex upgrade happens more like gcc upgrades. So testing both versions are much easier and, if needed, we can specify older version ones. > > Much worse, there are a couple of cases where we had to NMU the > > packages, either because the maintainers where inactive, or in one case > > because he said "no time here, just go ahead". Except for this one case > > this couldn't have been done with the packages in experimental, since > > failing to cooperate with a package in experimental isn't RC, is it? > > Not only do you not have to have an RC bug as an excuse to NMU; but > uploads to experimental (which these presumably would be) have even less > need for care and caution. > > > Of course, in principle, we could have created our own > > "compatible_with_teTeX-3.0" repository and uploaded fixed packages > > there, and do all the testing there. But then I don't understand what > > unstable is for... > > Generally, experimental fits the above role. Unstable's for uploading new > development of packages that will hopefully work, but might turn out not > to. In particular, though, they need to be fixed pretty quickly -- six > months in experimental, and another two so far in unstable isn't quickly. I agree. > > Yes, the problem is that bugs in other packages keep popping up slowly. > > Like #341849 in debiandoc-sgml: We already had checked that > > debiandoc-sgml didn't have one of the "usual" incompatibility bugs, but > > then it turned out that there is still one, which is only triggered when > > a far-east document is typeset in a certain encoding. It was FTBFS for documentation packages which used debiandoc-sgml. > "A far-east document is typeset in a certain encoding" doesn't sound like > an RC bug; and therefore not something that should hold up transitioning > to testing. Certainly, fix it ASAP once it's found, but that's the > desired result for any bug. Exactly. I should have reduced severity. ... > > That would be bad, but I can't see how I can speed up tetex's evolution > > to be releasable by letting it rot in experimental. > > That's true; the idea isn't to let it rot in experimental, it's to have > a quick pass through experimental that catches the most obscene bugs, > then to put it in unstable where you catch a few more, then to let > things progress to testing naturally, if necessary by having the RMs > remove tetex related packages that aren't getting updated to the latest > version in a timely or successful fashion. I think one to ease tension is to make tetex packages to coexist in archive just like many gcc. Current strict FTBFS rule will likely to make many documentations provided only in HTML, I think. Because fixing TeTeX related PDF/PS generation issues are quite difficult with short notice without tetex maintainer helping us. (They usually do.) We do not have soft and slow transition like gcc. I hope situation will be better soon but I am still struggling why debiandoc-sgml-doc fails to build nicely. (Yes, I know I can get by by not checking exit code during build process. But that is not a good fix I want to do.) Any help is appreciated. Osamu
Attachment:
signature.asc
Description: Digital signature