Ticket #2120 (in_testing defect)

Opened 8 years ago

Last modified 8 years ago

opkg doesn't install all files on upgrade

Reported by: koen Owned by: tick
Priority: normal Milestone:
Component: opkg Version:
Severity: normal Keywords:
Cc: Blocked By:
Blocking: Estimated Completion (week):
HasPatchForReview: no PatchReviewResult:
Reproducible:

Description

root@omap3evm:~# opkg install e-wm-images
Package e-wm-images (0.16.999.043+svnr37324-r17.1) installed in root is up to date.

root@omap3evm:~# opkg search /usr/share/enlightenment/data/images/test.png
e-wm-images - 0.16.999.043+svnr37324-r17.1 - /usr/share/enlightenment/data/images/test.png

root@omap3evm:~# file /usr/share/enlightenment/data/images/test.png
/usr/share/enlightenment/data/images/test.png: cannot open `/usr/share/enlightenment/data/images/test.png' (No such file or directory)

root@omap3evm:~# opkg install e-wm-images -force-reinstall
Reinstalling e-wm-images (0.16.999.043+svnr37324-r17.1) on root...
Downloading http://www.angstrom-distribution.org/feeds/2008/ipk/glibc//all/e-wm-images_0.16.999.043+svnr37324-r17.1_all.ipk
Configuring e-wm-images

root@omap3evm:~# !file
file /usr/share/enlightenment/data/images/test.png
/usr/share/enlightenment/data/images/test.png: PNG image data, 16 x 16, 8-bit/color RGBA, non-interlaced
root@omap3evm:~#

I suspect this is related to -force-overwrite, which is needed because opkg doesn't install all packages in the right order when files moved between packages.

Change History

comment:1 Changed 8 years ago by tick

  • Status changed from new to accepted

comment:2 Changed 8 years ago by tick

Hmmm... Interesting....
I will take a look of this when I finished my current tasks.
Which opkg version do you used?
Do you have the log for installing or actual upgrading e-wm-images for first time?
Did it say everything okay?

Thanks you.

comment:3 Changed 8 years ago by tick

  • Status changed from accepted to in_testing

Hi Koen,

I found a bug that may cause update file ownership wrongly, and fix in SVN 4830.
It's a hash_table implementation issue.
This bug will relate to files moving from one package to another.

Because I cannot reproduce your issue, could you test this for me?
Thanks.

Tick

comment:4 Changed 8 years ago by koen

I tested r4838 and that didn't seem to break anything. Although I haven't been able to reproduce the bug, I can't be 100% it's gone.

comment:5 Changed 8 years ago by tick

Thank you for testing this.
I will testing this for a while and see if this happen again.
Though I cannot reproduce this neither yet, I wrote a test script in my sandbox to check if this issue happens. And I will using that scrip every time I install/upgrade/remove something.

Note: See TracTickets for help on using tickets.