Created attachment 726 [details] take-out-packages-line.png If we cannot provide some information, we should not display the label for that information. In the image details screen, we cannot provide the packages information when you open the image using the 'Images' button. Therefore, we should not display the "Packages included: N/A" line. See the attached screenshot to see how it should look like.
Unlike the kernel version of this bug (3002), I don't see any workarounds for this as even if we dug into the image, some images fon't include information about installed packages. That said, rather than removing the label, I would prefer to see a message as to why the information is not being displayed. Removing UI elements (rather than disabling them or somehow indicating why they are not applicable) can be very disorienting in my experience strictly as a user of graphical interfaces.
Hi Darren: I agree that explaining why the information is not available is a better approach. Would you like to suggest something? Then we can get Scott to have a look at it. Thanks! Belen
Scott, Can you provide a message so we can make the change? Thanks.
Hmmm.... From the comments it is not really apparent why package information cannot be displayed other than the fact that we simply don't have access to the information. Supposing a user clicks and expects to see package information then maybe some of the following might work? * Unable to determine package information for this image. * Package information unavailable for this image. * We cannot provide package information for this image. * We are unable to display package information for this image. If there is a solid technical reason we can give then I would suggest providing that. I don't know the reason though. Scott
Scott, I think you are right. Darren's suggestion was about explaining why the information is not available. If we can only provide a generic message, I rather not display it. Jessica or Darren: would you be able to explain to us the reason why the package information for an image built in the past cannot be determined? Thanks! Belen (In reply to comment #4) > Hmmm.... From the comments it is not really apparent why package information > cannot be displayed other than the fact that we simply don't have access to > the information. Supposing a user clicks and expects to see package > information then maybe some of the following might work? > > * Unable to determine package information for this image. > * Package information unavailable for this image. > * We cannot provide package information for this image. > * We are unable to display package information for this image. > > If there is a solid technical reason we can give then I would suggest > providing that. I don't know the reason though. > > Scott
I'm really not familiar with the Hob codebase. Where does it get the package information to display when it can display it? I presume from the work dir where the packages are stored? If that is the case, when selecting an image that we don't have the work dir for, we can't display package information. Assuming the above is accurate (someone that knows this code should confirm), then perhaps something like: "No packaging information available for images without the underlying work directory."
Hi Cristian, Could you help us check if Darren's assumption is correct, i.e., we can only display the package information for those images for which we can access the work directory? Having said that, providing a mechanism to retrieve the full image details independently of when it was built or if the work directory is accessible, and populate the packages table from it, would be a significant workflow improvement. I could build an image today, come back tomorrow, retrieve it from my list of images, select to edit the packages and tweak it / change it without having to go through the process of selecting my machine, base image and recipes again. I am guessing this is what the templates do, but not everybody will create a template, so doing it by default should be a real win. Belen (In reply to comment #6) > I'm really not familiar with the Hob codebase. Where does it get the package > information to display when it can display it? I presume from the work dir > where the packages are stored? > > If that is the case, when selecting an image that we don't have the work dir > for, we can't display package information. > > Assuming the above is accurate (someone that knows this code should > confirm), then perhaps something like: > > "No packaging information available for images without the underlying work > directory."
I have investigated a bit in this area and found that the Package details that are shown after an image is built is received as a package model (that include all the packages that were included at image build time) from bitbake after sending a request event. The fact is that I not exactly sure how this information can be retrieved for older images, if it is stored in any place. I have seen that there is do_rootfs log where there is a list of packages (maybe we can use this to retrieve package details ?) that looks like this for core-image-minimal on qemux86: ~/git-repos/poky-master/build/tmp/work/qemux86-poky-linux/core-image-minimal-1.0-r0/temp [package_included] $ cat log.do_rootfs|grep "#####" Preparing... ################################################## ncurses-terminfo-base ################################################## base-files ################################################## libc6 ################################################## bash ################################################## base-passwd ################################################## libtinfo5 ################################################## Preparing... ################################################## udev-utils ################################################## usbutils-ids ################################################## pciutils-ids ################################################## packagegroup-core-boot ################################################## busybox-udhcpc ################################################## busybox ################################################## busybox-syslog ################################################## kernel-module-uvesafb ################################################## udev-extraconf ################################################## libusb-1.0-0 ################################################## libkmod2 ################################################## modutils-initscripts ################################################## busybox-hwclock ################################################## initscripts ################################################## update-alternatives-cworth ################################################## netbase ################################################## update-rc.d ################################################## sysvinit-inittab ################################################## update-modules ################################################## kernel-module-cfbfillrect ################################################## kernel-3.4.11-yocto-standard################################################## kernel-module-cfbimgblt ################################################## kernel-module-cfbcopyarea ################################################## tinylogin ################################################## sysvinit ################################################## sysvinit-pidof ################################################## v86d ################################################## libusb-0.1-4 ################################################## udev ################################################## kmod ################################################## Is there any other place that bitbake saves this information for built images ?
Any chance Jessica, Paul or Darren know the answer to Ioana's question? Thanks!
No, we don't store this anywhere else. In order to make this work we will have to explicitly write a file alongside the image file which lists the configuration selected by the user for the image so we can reload it the next time (and this is not just the package selections). Fortunately we already have code to do this. BTW, surely the "packages included" count is just the count of packages selected within Hob? This will be less than the number of packages actually installed (as seen in the log above).
I did some tests, and it seems that the number of packages in 'Image details' shows the packages included within Hob. And indeed, the packages listed in the log are the ones actually installed, which are more than the ones selected by the user. The code that you are reffering to already writes a file for packages selected, or just collects this information and if the first should we use it for this bug on 1.3M5 ?
I think it's too late to fix this for 1.3. The code I'm referring to is the code that is used for saving templates - it should also be usable for saving the configuration that went into the image alongside it.
Let's move to the next release then. Thanks! (In reply to comment #12) > I think it's too late to fix this for 1.3. > > The code I'm referring to is the code that is used for saving templates - it > should also be usable for saving the configuration that went into the image > alongside it.
Ioana, do you need any more information for this issue?
reassign to critiana
After a technical assessment with Ross B and Richard P we have concluded that implementing this feature requires substantial engineering effort and we don't have available resources to deliver it in 1.5 Changing target milestone to 'future'.
At this point, work will take place on toaster, not hob, so marking as won't fix.