| Summary: | RPM backend cannot handle RPROVIDES in IMAGE_INSTALL | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Paul Eggleton <bluelightning> |
| Component: | core | Assignee: | Robert Yang <liezhi.yang> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium | CC: | hongxu.jia, kergoth, liezhi.yang, mark.hatle, meta.mr.watcher, meta.watcher, otavio, sgw, sstncr |
| Version: | 1.5 | ||
| Target Milestone: | 2.0 | ||
| Hardware: | All | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
|
Description
Paul Eggleton
2013-08-20 09:57:47 UTC
I'm not sure if SMART will allow you to install based on a dependency instead of the actual package name. This is something we will have to explore. Typically on RPM based systems, installing is done based on package name -- and the dependencies are only for inter-package activities. We may have to adjust the name translation code to check the RPROVIDES fields and translate that as well. I think the first step is to check if SMART can even do a dependency based install, and then weigh our options from there. One other potential issue w/ a dependency based installed. Dependencies are "architecture neutral". So even if dependency based installs work, there is likely no way to tell SMART I want a dependency of a particular architecture type. (again if dependencies work, that should be verified as well.) I've just checked, smart is capable of handling RPROVIDES and not just package names: ------------ snip ------------ root@qemux86:~# smart install glibc-utils Loading cache... Updating cache... ############################ [100%] Computing transaction... Installing packages (1): eglibc-utils-2.17-r3@i586 154.8kB of package files are needed. 375.8kB will be used. ------------ snip ------------ *** Bug 5716 has been marked as a duplicate of this bug. *** *** Bug 6918 has been marked as a duplicate of this bug. *** Hi Paul, Here is my fix: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=hongxu/fix-rootfs&id=65b3eb26c246 OK, so your fix looks reasonable, but as I tried to convey in the first comment above, I really think that a lot of this logic should be handled by Smart itself. We should be asking it to install a particular package or provider and it should be working out what should provide that item - if at all possible other than the normal OE package name to real package name (e.g. eglibc -> libc6) we shouldn't need to do any translation on the list before sending it to Smart. Perhaps we can take this fix now and refactor things later, but I worry that refactoring will never get done. I've replied on the mailing list; the fix may be OK but I really think we need some performance impact figures. I'm marking this as M4, and we should be able to take it in M4 if we get overall performance numbers (as Richard noted on the mailing list) and they are reasonable. Just a ping to check the status on this, is still still pending performance testing from Hongxu? |