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

Bug#366907: tetex-bin: Fails to configure, updmap failed



On Sun, May 14, 2006 at 12:12 -0400, Liam Healy wrote:
> On 5/14/06, Ralf Stubner <ralf.stubner@web.de> wrote:
> 
> >Meanwhile this makes sense to me. 05TeXMF.cnf is managed by ucf, and ucf
> >sees that the 'previously installed' version and the 'to be installed'
> >version have the same md5sum, hence my changed version is preserved, as
> >it is supposed to be.
> 
> Which seems like a defect in the change-detection algorithm.  Why are
> the md5sums of the different files the same?   Wouldn't it make more
> sense to use "diff" to see if there's a difference?  In any case, this
> doesn't explain my experience; my md5sums are very different:
> ec6c37a0d317ed545a3e66409cf54630  05TeXMF.cnf-home
> dd2b65e95a497637be4033ecbecdd2bd  /etc/texmf/texmf.d/05TeXMF.cnf

Sorry for being unclear. I think the behaviour is correct in the case
that I investigated and I will try to explain this in a second. I don't
know exactly what you did, so I can't tell if my analysis applies there,
too. Anyway, what I did plus some interpretation:

apt-get install tex-common
  [here the original 05TeXMF.cnf from the maintainer gets installed and 
   its md5sum registered with ucf.]
apt-get remove tex-common
  [no changes to 05TeXMF.cnf]
vi /etc/texmf/texmf.d/05TeXMF.cnf
  [05TeXMF.cnf gets changed and hence gets a new md5sum]
apt-get install tex-common
  [here ucf has to compare /three/ md5sums:
    . the registered one from the first step
    . the md5sum of /etc/texmf/texmf.d/05TeXMF.cnf
    . the md5sum of 05TeXMF.cnf in the package
   ucf sees that the first and the third md5sum are identical and
   therefore does not ask the admin about the changes. This is correct
   behaviour since the admin purposely changed the config file, and these
   changes should be maintained. Only when the debian maintainers change
   the shipped config file, ie the first and third md5sum are not
   identical, the admin gets notified.]  

As I said, I think everything is correct here.

> >> Even though the settings in 05TeXMF.cnf
> >> would /break/ the system, since TEXMFDIST is not set, the checks in
> >> tex-common's postinst did /not detect/ this! What is going wrong here?
> >
> >I think I have found an explanation for this. In check_texmf() in the
> >postinst script, $checkfailed is allways set to false in the beginning.
> >Hence if some check in the middle fails but the last one not, this is
> >not detected. Moving the failing chack to the end or removing that line
> >makes the postinst fail. However, it fails without any further notice,
> >so I think this is not the whole story. All the debconf stuff in
> >check_texmf() does not work within my pbuilder. Strange ...
> 
> I don't understand this; I don't know what "fails without any further
> notice" means, but it certainly seems like a bug.

If I change on my real sytem /etc/texmf/texmf.d/05TeXMF.cnf in such a
way that TEXMFDIST is not definied and call 'dpkg-reconfigure
tex-common', this change is detected by the posinst script and a debconf
message appeares telling me that I should fix the defintion of
TEXMFDIST. For whatever reason I don't get this in my pbuilder. I have
only managed to have it exit with exit code 1 (ie failure). But this
deconf message telling me what is wrong never appeared.

The same goes for the deconf messages concerning the font cache. That
might be related to the two recent bug reports about /var/cache/fonts
not being world writable by default.

cheerio
ralf




Reply to: