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

Re: Problem with the "updmap scheme" when a font package is in an "inconsistent state"



Frank Küster <frank@debian.org> wrote:

> You are right.  I don't like relying too much on details of dpkg
> implementation, therefore I was looking for something else.

Yeah, I know...

>  However, naming files dpkg-new is probably not going to change; I
> guess more things depend on that. Not being able to extend this to the
> other update- scripts is really a strong argument, so let's check for
> dpkg-new.

I have another proposal. Not more complex, maybe cleaner, but slower
than checking for .dpkg-new.

We can use dpkg-query in update-updmap[1]. This would work the same as
it currently does, except that, when
/var/lib/tex-common/fontmap-cfg/lmodern.list is found (which means
lmodern is at least unpacked), update-updmap calls:

  dpkg-query -s lmodern | grep '^Status: '

and updates updmap.cfg iff the result matches:

  'Status: .+ .+ (half-configured|installed)'

We don't want to act only when the state is 'installed', because that
way, we couldn't configure lmodern properly: its postinst calls
update-updmap in state 'half-configured', *after* the conffiles have
been updated, and this update-updmap call mustn't be ignored.

With a little optimization (using a temporary file to store a table
indicating the status of every package under
/var/lib/tex-common/fontmap-cfg/), one could afford to run dpkg-query
only once per update-updmap run. This takes 1.1 second on my system
(Athlon XP 1800+). This is much slower than checking the .dpkg-new, but
maybe acceptable (for users, yes; for us: a kind of a pain when doing
the install/remove/upgrade tests!).

Yet Another Option (in order to save time) is to parse
/var/lib/dpkg/status with sed, considering this:

,----[ http://lists.debian.org/debian-python/2006/06/msg00239.html ]
| According to the dpkg maintainers, /var/lib/dpkg/status is public enough
| to be used. tools like grep-dctrl use this file as well.
`----

but it's more or less on the same level of ugliness as checking for
.dpkg-new files, only more complex (and slower).

Open question: is there any need to bother with the second field in the
'Status' line (the one that usually reads 'ok')? That would be the case
if dpkg can set 'half-installed' in the third field while the conffiles
have *not* been updated properly (broken stuff, I don't know).

What do you think?


Little experiment to back up the dpkg-query method
--------------------------------------------------

# dpkg -P foo
(Reading database ... 123489 files and directories currently installed.)
Removing foo ...
Purging configuration files for foo ...
# dpkg-query -s foo | grep '^Status: '
Status: purge ok not-installed
# dpkg -i ~flo/debian-experiments/foo/foo_1.0-2_all.deb
Selecting previously deselected package foo.
(Reading database ... 123485 files and directories currently installed.)
Unpacking foo (from .../foo/foo_1.0-2_all.deb) ...
Setting up foo (1.0-2) ...
Running foo.postinst configure 
dpkg-query says: 'Status: install ok half-configured'

# dpkg-query -s foo | grep '^Status: '
Status: install ok installed
#


 [1] Well, update-fontlang; I use the particular case of lmodern and map
     files for this discussion, but it really applies to update-fontlang
     in general.

-- 
Florent



Reply to: