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

Bug#291545: tetex-bin: initex fails to generate some etmf files



On 24.01.05 Frank Küster (frank@kuesterei.ch) wrote:

Hi Frank,

That bug is 5 years old.

> severity 291545 normal
> retitle 291545 upgrade of files in texmf.d shows diff twice (plain ucf and update-texmf)
> stop
> 
> Margarita Manterola <marga@marga.com.ar> schrieb:
> 
> > Now, the fact is that it asked me the same question twice (now that the
> > mistery is solved, I have the sensation that I remember looking at the diff
> > and thinking "isn't this the same diff I saw before?"), therefore causing
> > my making the mistake of not accepting it twice.
> >
> > Is there a way to prevent this?  Some way of "preseeding" update-texmf so
> > that it doesn't happen?
> 
> Actually, I fear it is not possible. We *could* make things easy and
> straightforward: If we would put the generated texmf.cnf file into
> /var/lib/texmf, then only the files in texmf.d would be configuration
> files, and only there could a question come. By the way, the reason for
> all this is to enable other packages to add their own configuration to
> texmf.cnf, like e.g. jadetex does.
> 
> However, the problem with this is that texmf.cnf is known as "the"
> configuration file for teTeX, it is referenced in many README files or
> tutorials, and, to make things worse, since it must always be possible
> for TeX to find it, users can find it with the same means:
> 
>  kpsewhich --format='web2c files' texmf.cnf
> /usr/share/texmf/web2c/texmf.cnf
> 
> (actually you can use it without the --format stuff). This is why we
> have chosen to keept texmf.cnf in /etc/texmf, as a configuration file -
> people would have edited anyway. But this makes the double checking
> necessary. 
> 
> > Now, this bug was not a bug, but a human's (namely, me) fault, yet I feel 
> > that something should be done to prevent this from happening again, don't 
> > you think?
> 
> Yes, it would be good. I'll think it over, and keep the bug open under a
> different title, and with lower severity.
> 
Are you still willing to work on this or should we simply close it, in
the hope that TL is not affected?

H.
-- 
sigmentation fault



Reply to: