[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: FTBFS for Archetecture all package (Bug#167049)



Thanks Junichi,

On Tue, Nov 05, 2002 at 03:28:58PM +0900, Junichi Uekawa wrote:
> At Sun, 3 Nov 2002 21:47:31 -0800,
> Osamu Aoki wrote:
> > > > > Does documentation package of "Architecture: all" which has
> > > > > been build properly in the stable but not in the unstable due
> > > > > to tetex differences deserve to receive "serious" bug (RC bug)
> > > > > report or not?
> > > > Yes, since it HAS the bug. It should, however, be tagged "sid",
> > > > to make it clear that the package in "woody" doesn't have the
> > > > problem.
> > > This is completely unnecessary, for reference. 
> > Just to be sure.  
> > You mean SGML/TEX source for the reference document which is picky
> > on the version of TEX used to build is acceptable an non RC bug
> > package even if Junichi's autobulder can not handle it.

s/can not handle/will reject/   (Sorry, I made wrong impression)

> Why would it mean any different if my autobuilder does not handle it.
> It required manual interaction that is undocumented to build, working
> around a bug in tetex package postinst.

The way I used to write TEX configuration was very TEX version specific.
Ignorance made a fearless person, me :-)

> If the bug in tetex is fixed, then the bug is closed.

TEX is migrating to the new file arrangement.  It is not a bug issue.
I think it is a moving target problem.  I do not want to write a build
dependence to be limited to the current version.

> > Generated text (HTML/PS/PDF/PLAIN TEXT) are all usable.
> 
> If the generated text is usable, it is good enough for a web page, but
> not for a Debian package.

I agree that these documentation build bugs are RC bugs on the letter of
policy.  It is a very good thing if RC bugs are filed early phase of
testing cycle.  As you said on the other thread, it weeds out
unmaintained documentation packages.

I finally figure out how to minimize TEX version dependence of package
per Julian Gilbey and Atsuhito Kohda's help today.  I fixed it in my
CVS. So I hope this will not happen again for me.  (Otherwise, I was
expecting another problem soon.)

But for all practical purposes, do not you see some merits of allowing
these documentation to be a part of the archive as long as their content
has been updated from the last major release and content is readable?
I know you may likely disagree here, though.

I think PDF and PS files will be nice for printing but they are
problematic building :-)

Some documents in archive are not build during build period with TEX.  I
see several packages include compiled version of PS file together with
TEX source in the source tar.  They sure will survive your test but who
knows how they build.  Providing PS and PDF are generally a good
direction. (File size issues aside.)

Anyway, I hope my new script is bullet proof to the next version of TEX.

Cheers.
-- 
~\^o^/~~~ ~\^.^/~~~ ~\^*^/~~~ ~\^_^/~~~ ~\^+^/~~~ ~\^:^/~~~ ~\^v^/~~~ +++++
        Osamu Aoki <osamu@debian.org>   Cupertino CA USA, GPG-key: A8061F32
 .''`.  Debian Reference: post-installation user's guide for non-developers
 : :' : http://qref.sf.net and http://people.debian.org/~osamu
 `. `'  "Our Priorities are Our Users and Free Software" --- Social Contract



Reply to: