| Submitter | Denys Dmytriyenko |
|---|---|
| Date | 2010-02-24 20:52:52 |
| Message ID | <1267044772-10182-1-git-send-email-denis@denix.org> |
| Download | mbox | patch |
| Permalink | /patch/1627/ |
| State | Changes Requested |
| Headers | show |
Comments
On Wed, 2010-02-24 at 15:52 -0500, Denys Dmytriyenko wrote: > New opkg requires full and correct package name, version, revision and > architecture to be specified when requiring de-installation of a package. > Collect that info from opkg-info. This seems like a bug in opkg. Would it not be better to fix it there? p.
On 25 February 2010 07:30, Phil Blundell <philb@gnu.org> wrote: > On Wed, 2010-02-24 at 15:52 -0500, Denys Dmytriyenko wrote: >> New opkg requires full and correct package name, version, revision and >> architecture to be specified when requiring de-installation of a package. >> Collect that info from opkg-info. > > This seems like a bug in opkg. Would it not be better to fix it there? > > p. > This is an unintended side effect of other changes, however I'm not sure that I consider it inappropriate behaviour. That status does apply to a particular package version, does it not? -Graham
On Thu, 2010-02-25 at 08:18 +1030, Graham Gower wrote: > This is an unintended side effect of other changes, however I'm not > sure that I consider it inappropriate behaviour. That status does > apply to a particular package version, does it not? No, the SW_xx flags should apply to any version and architecture rather than being nailed down to a specific tuple. Otherwise, these flags would be subverted as soon as a new version appears in the feed. p.
On Wed, Feb 24, 2010 at 09:59:26PM +0000, Phil Blundell wrote: > On Thu, 2010-02-25 at 08:18 +1030, Graham Gower wrote: > > This is an unintended side effect of other changes, however I'm not > > sure that I consider it inappropriate behaviour. That status does > > apply to a particular package version, does it not? > > No, the SW_xx flags should apply to any version and architecture rather > than being nailed down to a specific tuple. Otherwise, these flags > would be subverted as soon as a new version appears in the feed. The thing is, those SW_xx flags are not preserved anyway - the status file is primed with BAD_RECOMMENDATIONS (Status: deinstall), but later gets overwritten by the list of only installed packages. Of course, "deinstall" packages are being skipped, but they are not preserved in the status file for later use... But, on the other hand, if there are multiple versions of the package present in the deploy/feed, then it will, probably, deinstall one version and install another one, which is not the correct behavior.
On Wed, 2010-02-24 at 18:06 -0500, Denys Dmytriyenko wrote: > The thing is, those SW_xx flags are not preserved anyway - the status file is > primed with BAD_RECOMMENDATIONS (Status: deinstall), but later gets > overwritten by the list of only installed packages. Of course, "deinstall" > packages are being skipped, but they are not preserved in the status file for > later use... Ah. If that's happening then that is also a bug. Are you saying that opkg basically throws away anything that isn't SS_INSTALLED when it writes out the status file? That is definitely no good: it ought to preserve all the SW_xx values that are set in the status file, essentially indefinitely. > But, on the other hand, if there are multiple versions of the package > present in the deploy/feed, then it will, probably, deinstall one > version and install another one, which is not the correct behavior. Yeah, that would also be pretty broken. p.
Patch
diff --git a/classes/rootfs_ipk.bbclass b/classes/rootfs_ipk.bbclass index 38d6121..c32e4e3 100644 --- a/classes/rootfs_ipk.bbclass +++ b/classes/rootfs_ipk.bbclass @@ -36,16 +36,19 @@ fakeroot rootfs_ipk_do_rootfs () { mkdir -p ${IMAGE_ROOTFS}${libdir}/opkg/ STATUS=${IMAGE_ROOTFS}${libdir}/opkg/status + + opkg-cl ${IPKG_ARGS} update + # prime the status file with bits that we don't want for i in ${BAD_RECOMMENDATIONS}; do - echo "Package: $i" >> $STATUS - echo "Architecture: ${TARGET_ARCH}" >> $STATUS - echo "Status: deinstall ok not-installed" >> $STATUS - echo >> $STATUS + infln="`opkg-cl ${IPKG_ARGS} info $i | grep -e '^Package:' -e '^Architecture:' -e '^Version:'`" + if [ ! -z "$infln" ]; then + echo "$infln" >> $STATUS + echo "Status: deinstall ok not-installed" >> $STATUS + echo >> $STATUS + fi done - opkg-cl ${IPKG_ARGS} update - # Uclibc builds don't provide this stuff... if [ x${TARGET_OS} = "xlinux" ] || [ x${TARGET_OS} = "xlinux-gnueabi" ] ; then if [ ! -z "${LINGUAS_INSTALL}" ]; then
New opkg requires full and correct package name, version, revision and architecture to be specified when requiring de-installation of a package. Collect that info from opkg-info. Signed-off-by: Denys Dmytriyenko <denis@denix.org> --- classes/rootfs_ipk.bbclass | 15 +++++++++------ 1 files changed, 9 insertions(+), 6 deletions(-)