[Top][All Lists]

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

Re: [AUCTeX-devel] preview-tetex RPM

From: David Kastrup
Subject: Re: [AUCTeX-devel] preview-tetex RPM
Date: Thu, 08 Jun 2006 19:07:48 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

Reiner Steib <address@hidden> writes:

> On Thu, Jun 08 2006, David Kastrup wrote:
>> Reiner Steib <address@hidden> writes:
>>> +# Make sure that this preview.cfg exists:
>>>  touch -a %{buildroot}%{_datadir}/texmf/tex/latex/preview/preview.cfg
>> Uh Reiner?
>> Thanks for your good opinion of me (I think the "touch ..." was also
>> by you), 
> Yes I added it when trying to make preview-tetex*.rpm work:
> ,----
> | 2006-06-07  Reiner Steib  <address@hidden>
> |     [...]
> | 
> |     * auctex.spec: Add "-n" for preview-tetex.
> |     (%install): Create preview.cfg.
> `----
>> but there is no file preview.cfg by default.  And never was.
>> I am merely an idiot.  What we have is "prauctex.cfg".  
> | %config %{_datadir}/texmf/tex/latex/preview/preview.cfg
> ... looked like it was intended.

Well, if it had been merely accidental, I would not have needed to
call myself names...  It was late in the evening, or something, and I
seemingly just cobbled something together, relying on intelligent
helpers to clear the mess up.  Too bad that those relied on having an
intelligent project manager...

>> Now the question is how to get rid of this nonsense in the next RPM
>> version.
>> Will it be sufficient to merely remove everything referring to the
>> non-existent preview.cfg?  Or will that leave a preview.cfg zombie
>> lying around from a previous installation?
> I did some testing:
> "rpm -e preview-tetex" removes it without a trace unless it has been
> modified.  After "echo "% foo" > preview.cfg", "rpm -e" leaves
> preview.cfg.rpmsave lying around.  So I'd expect that you suggestion
> would work correctly.  (Maximum RPM [1] isn't very clear on this.)

Ok, let's do it.  And then mark prauctex.cfg instead.  I think there
are even two types of "config files": one where modified versions are
kept completely, one where modified versions are backed up for
reference (but the new is installed anyway).  I think that the second
choice would be appropriate here: install the new one, but if the user
changed the old one, save it for reference.

David Kastrup, Kriemhildstr. 15, 44793 Bochum

reply via email to

[Prev in Thread] Current Thread [Next in Thread]