I've had numerous requests for a simple mechanism to remove a package. From initial investigation there seem to be two types of packages people want removed: * ones added explicitly to the system to install, such as via IMAGE_INSTALL. * ones added by dependencies during the final image install The solution should be able to address either case, as well be package type independent. If it's not possible to remove a package a warning or error should be generated with an explanation of the problem and how a user can resolve that issue. It might also be useful to "force" remove a package (in the dependency case), ignoring dependencies -- even if this results in a potentially broken filesystem.
*** Bug 4184 has been marked as a duplicate of this bug. ***
Paul, Please help with the design so WR PRC team help on the impl
Jeff Polk will be leading the development effort inside of Wind River. We have some preliminary thoughts on design, but we're still trying to figure out if any of the items are reasonable.
This is not deployment, but image generation.
Changing the title to better reflect what is being requested. We really want to avoid installing a package (and anything that depends on that package -- within reason.) For instance, someone should be able to say ignore 'perl', and avoid perl and it's who subsystem.
Mark and I have been discussing this, and that will almost certainly continue, but the implementation work so far has been done by him, so assigning to him - hope that's OK Mark :)
Paul -- fine with me. :) Code sent to oe-core for review/pull. http://lists.openembedded.org/pipermail/openembedded-core/2013-August/082683.html Note, the above implements the ability to prevent specify packages from ending up in the resulting filesystem. In the case where someone may want to remove a package that was installed. Using a suitable post-install script is the best answer and is NOT part of the implementation of this bug.
oe-core commits: 6d7f5581bbfaf174edb77d92846e720e8057481c 63c61b7c0c8aeb89661e3bb85e281dd1ef5b618c e36c9947c82be034133a27db6e0f7a769daeb185 86a30a88cf89ed97c372c391169f4ae243c89fd2 42b115b6d65c8205acb77b96db481f3e5172266b 2db14eaa0fcc080bc20fa9da985ffc05c3b21e2a 0341bfa886ea851f5a394051545b4e624d8003dd 6fd8141bbdcd84c591149d84ad84effc2357de72 238c46c03d0d9c35523c78b94bfebb57904bac5a 87660d636c2ebe76cd9dff2a334f135def9a0cf3 208d4d5ef7c5ead35dc27b7808f92ed377377aa4
Hi, I have added stuff to the documentation to cover the "Yes (doc changes required)" aspect of this feature. The bug was already marked "RESOLVED" and is assigned to Mark so I am not sure how to handle the flow of the bug now. So, I am keeping it marked as "RESOLVED" but changing the "Documentation change" field to say "Done (doc changes complete). This flow doesn't really account for a chance to review the doc changes that I have put in to complete work. Here are the sections added or changed in the manual: http://www.yoctoproject.org/docs/1.5/dev-manual/dev-manual.html#excluding-packages-from-an-image - A new section in the dev-manual overviewing how to exclude installation of a package. http://www.yoctoproject.org/docs/1.5/ref-manual/ref-manual.html#var-BAD_RECOMMENDATIONS - Updated the description of this existing documented variable. http://www.yoctoproject.org/docs/1.5/ref-manual/ref-manual.html#var-NO_RECOMMENDATAIONS - A new variable description. http://www.yoctoproject.org/docs/1.5/ref-manual/ref-manual.html#var-PACKAGE_EXCLUDE - A new variable description. Scott
Cannot verify due to this bug: https://bugzilla.yoctoproject.org/show_bug.cgi?id=5288 My scenario: make the following changes in local.conf: MACHINE ??= "qemux86-64" IMAGE_INSTALL_append = " man" PACKAGE_EXCLUDE = "man" PACKAGE_CLASSES ?= "package_ipk" NOTE: using package_rpm as PACKAGE_CLASSES does works without any error. Errors I have: | Running intercept scripts: | log_check: Using /media/ubu/240/poky/build/tmp/work/qemux86_64-poky-linux/core-image-sato/1.0-r0/temp/log.do_rootfs.20945 as logfile | Logfile is clean | makedevs: No entry for root in search list | WARNING: exit code 1 from a shell command. | ERROR: Function failed: do_rootfs (log file is located at /media/ubu/240/poky/build/tmp/work/qemux86_64-poky-linux/core-image-sato/1.0-r0/temp/log.do_rootfs.20945) ERROR: Task 7 (/media/ubu/240/poky/meta/recipes-sato/images/core-image-sato.bb, do_rootfs) failed with exit code '1' NOTE: Tasks Summary: Attempted 5327 tasks of which 5325 didn't need to be rerun and 1 failed. No currently running tasks (5326 of 5328) Summary: 1 task failed: /media/ubu/240/poky/meta/recipes-sato/images/core-image-sato.bb, do_rootfs Summary: There was 1 WARNING message shown. Summary: There was 1 ERROR message shown, returning a non-zero exit code. ubu@ubu-v:/media/ubu/240/poky/build$
| makedevs: No entry for root in search list The above error indicates that you do not have an /etc/passwd or /etc/group installed into your filesystem. So the 'root' user account can not be looked up and translated to uid 0. Check the system and figure out why passwd/group was not installed.
(In reply to comment #11) > | makedevs: No entry for root in search list > > The above error indicates that you do not have an /etc/passwd or /etc/group > installed into your filesystem. So the 'root' user account can not be > looked up and translated to uid 0. > > Check the system and figure out why passwd/group was not installed. Hi Mark, I am not sure if you are referring to the host machine or into the image that is being built. For the image that is being build, I don't have an etc/passwd or etc/group files created after the failure: [yocto@localhost build]$ ls -la /mnt/ssd/poky/build/tmp/work/qemux86_64-poky-linux/core-image-sato/1.0-r0/rootfs/etc/ In the case you are referring to the files in my machine, I have the following: [yocto@localhost build]$ cat /etc/group | grep root root:x:0: [yocto@localhost build]$ cat /etc/passwd | grep root root:x:0:0:root:/root:/bin/bash operator:x:11:0:operator:/root:/sbin/nologin [yocto@localhost build]$ I also tested in other machines, and I have the same failure. Regards, Alex.
The error from makedev indicates that /etc/passwd and /etc/group are not available within the image that is being generated. This is a fatal error to say the least.
(In reply to comment #13) > The error from makedev indicates that /etc/passwd and /etc/group are not > available within the image that is being generated. This is a fatal error > to say the least. I'll open a separate bug for my error, since I don't think it's really related to #5288 as I mentioned in an above comment. The bug has been fixed and verified, but for me it doesn't work.
Submitted this: https://bugzilla.yoctoproject.org/show_bug.cgi?id=5311
Ok, so I have tested all parameters involved: BAD_RECOMMENDATIONS, NO_RECOMMENDATIONS, PACKAGE_EXCLUDE. I can mention that with NO_RECOMMENDATIONS set to 1, a core-image-sato boots, but X failed to start. I don't know if this is a problem but I can confirm that the feature works. Still I can't mark it as verified until https://bugzilla.yoctoproject.org/show_bug.cgi?id=5311 is fixed.
Reopened since the issue https://bugzilla.yoctoproject.org/show_bug.cgi?id=5311 is present, and the feature doesn't work entirely
Setting to Resolved Fixed, as the primary functionality is implemented. Verification depends on Bug 5311 being complete.
(In reply to comment #18) > Setting to Resolved Fixed, as the primary functionality is implemented. > > Verification depends on Bug 5311 being complete. Hi Mark, Can you elaborate a little bit? Is the feature ready and the 5311 isn't related to it's implementation but still blocks its verification?
The work planned for this enhancement was to add the mechanisms wherever it was possible to. The mechanism was added to opkg (subject of the 5311 bug), and works in some cases, just not in the specific case from 5311. In the bug triage meeting, it was decided that we have shown that the functionality is implemented, but there are bugs in other parts of opkg that are preventing it from working as expected. So we want to make sure 5311 stays open to track the "new" defect and hopefully fix when it comes. And this item stays in the resolved state. Once 5311 is complete, this bug should be set to verified.