Bug#500916: hal: FDI cache does not get updated when installing .fdi files from packages

[Martin Pitt]

Package: hal
Version: 0.5.11-3
Tags: patch
User: ubuntu...@lists.ubuntu.com
Usertags: origin-ubuntu intrepid ubuntu-patch

Hi!

It already occurred several times to me that people had trouble with
FDI files which were apparently not "picked up" by hal. One particular
case is https://bugs.launchpad.net/bugs/275825, where I finally saw
the light: time-based comparison of .fdi files vs. the cache, as done
in di_cache_coherency_check(), doesn't work with dpkg, which maintains
the original file timestamps on unpack.

The quick fix for this is to remove the cache in the init script,
which I just did in Ubuntu (we are close to release). It sacrifices
most of the startup speed improvement unfortunately, and hal still
won't pick up fdi changes immediately, but at least it will work after
a reboot.

The more correct long-term solution could be to create a
dh_install_hal_fdi which generates
/usr/lib/hal/hald-generate-fdi-cache postinst snippets, and convert
all packages shipping .fdi files to use it. But that's not really
adequate for Lenny, and with DeviceKit being on the horizon, it might
be obsolete before we even finish..

Thanks,

Martin

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

[Michael Biebl]

Hi Martin,

I had a short discussion with lool on irc, and we had an alternative idea:
Install a dpkg trigger.
For the etch -> lenny upgrade, we would regenerate the fdi cache in hal
postinst as we can't rely on the dpkg triggers functionality yet.

Do you see any downsides of this approach?
It would we much less work than a dh_fdi and avoid the costly
regeneration on each boot.

Cheers,
Michael

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[Martin Pitt]

Hi Michael,

Michael Biebl [2008-10-03 21:48 +0200]:

> I had a short discussion with lool on irc, and we had an alternative idea:
> Install a dpkg trigger.

Ah, indeed that sounds like a great idea, and much less blunt than
changing the init script (sorry for the kneejerk patch, had to do
something quick to unscrew the Ubuntu upgrade to 8.10 beta).

However, so far I thought that dpkg triggers are triggered by postinst
scripts. There are triggers for "any package installed/upgraded", too?
I'm not very familiar with triggers, apparently you know more than me.
:-)

> For the etch -> lenny upgrade, we would regenerate the fdi cache in hal
> postinst as we can't rely on the dpkg triggers functionality yet.

Right, that makes perfect sense.

Thank you,

[Michael Biebl]

Martin Pitt wrote:
> Hi Michael,
>
> Michael Biebl [2008-10-03 21:48 +0200]:
>> I had a short discussion with lool on irc, and we had an alternative idea:
>> Install a dpkg trigger.
>
> Ah, indeed that sounds like a great idea, and much less blunt than
> changing the init script (sorry for the kneejerk patch, had to do
> something quick to unscrew the Ubuntu upgrade to 8.10 beta).
>
> However, so far I thought that dpkg triggers are triggered by postinst
> scripts. There are triggers for "any package installed/upgraded", too?
> I'm not very familiar with triggers, apparently you know more than me.
> :-)

Calling a trigger explicitely in postinst is only one possibility.

The one I had in mind would be a file based trigger.

This trigger would be installed by the hal package.
Whenever a package installs a file under /usr/share/hal/fdi, the trigger
would be activated. So we don't need to modify all packages shipping fdi
files.

I've committed a proposed fix as r2435 [1]

>> For the etch -> lenny upgrade, we would regenerate the fdi cache in hal
>> postinst as we can't rely on the dpkg triggers functionality yet.
>
> Right, that makes perfect sense.

Actually, as sjoerd correctly noticed, we don't even need that, as the
etch version doesn't have a cache yet ;-)

Have a nice weekend,
Michael

[1] http://svn.debian.org/wsvn/pkg-utopia/?rev=2435&sc=1

[Loïc Minier]

On Sun, Oct 05, 2008, Michael Biebl wrote:
> Actually, as sjoerd correctly noticed, we don't even need that, as the
> etch version doesn't have a cache yet ;-)

Except for lenny/sid -> lenny/sid upgrades perhaps?

--
Loïc Minier

--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

[Michael Biebl]

Loïc Minier wrote:
> On Sun, Oct 05, 2008, Michael Biebl wrote:
>> Actually, as sjoerd correctly noticed, we don't even need that, as the
>> etch version doesn't have a cache yet ;-)
>
> Except for lenny/sid -> lenny/sid upgrades perhaps?
>

Yeah, right. The cache might be outdated for lenny/sid users.

For sid users it wouldn't be that much of an issue, as a new hal-info
package is coming sooner or later (I'd say sooner, see hal-info 20081001
which was released just a few days ago) which would trigger a cache update.
If we try to get this hal-info version into lenny, then we wouldn't need
it either for users upgrading from lenny->lenny.

Cheers,
Michael

[Michael Biebl]

severity important
thanks

I'm raising severity to important as I'd like to see this fix making it
into lenny.
There are quite a few packages now that ship fdi files and the current
behaviour, as Martin already mentioned, can lead to problems, which are
very hard to understand and debug for the user.