On 17/01/2014 14:13, "Barros Pena, Belen" <[email protected]> wrote:
>So, Alex pulled out some real data, and Paul clarified some special cases >about RDEPENDS/RRECOMMENDS vs TRDEPENDS/TRRECOMMENDS. In most cases, both >sets of dependencies will be exactly the same, so no problem there: we can >simply display RDEPENDS. > >But there are two more cases we need to deal with: > >1. Additional TRDEPENDS might exist caused by the presence of certain >files. For example, a shell script will require a shell provider. In this >case, we suggest the installed package details page shows RDEPENDS + >additional TRDEPENDS. From a UI point of view, those additional TRDEPENDS >look exactly like the RDEPENDS, although we might try to give some more >details about those in the future. > >2. Packages are renamed during packaging (for example, eglibc might be >renamed to libc6). In this case, we end up with 2 dependencies (one >RDEPENDS and one TRDEPENDS) that are really the same, just with a >different package name. For example, for udev-utils, you might have >RDEPENDS as follows: > >util-linux-libblkid >eglibc >libkmod > >And TRDEPENDS as follows: > >libblkid1 >libc6 >libkmod2 > >These are not 6 different dependencies: they are only 3. What happened is >that util-linux-libblkid was renamed to libblkid1; eglibc to libc6 and >libkmod to libkmod2. For these cases, we are thinking of mapping the >RDEPENDS package names to the TRDEPENDS package names (see Bugzilla entry >5739 assigned to AlexD). So in the example above, Toaster would report 3 >dependencies only, not 6. I am working on how these renamed package >dependencies could be displayed in the UI. I should have something on >Monday. Sorry for the enormous delay. How to handle different package names is now available at https://bugzilla.yoctoproject.org/attachment.cgi?id=1749 See page 11. You can see it in action in the design prototype at: http://www.yoctoproject.org/toaster/package-included-details-trdepends.html #brought-in-by > >Questions, comments, suggestions, general wonderments? > >Thanks! > >Belén > > > >On 16/01/2014 17:26, "Damian, Alexandru" <[email protected]> >wrote: > >>Speaking about RDEPENDS and TRDEPENDS, RRECOMMENDS and TRRECOMMENDS are >>analoguous. >> >> >>TDEPENDS is not just DEPENDS when installed, although this is the case in >>the majority of cases. >>What may happen is that DEPENDS points to a virtual package, which can be >>solved by any of a set of real packages, >> >>while TDEPENDS will always be solved by a real packages. >> >> >>Also, TDEPENDS for a single package may change with the target on which >>is installed !, so this is why we have the target field for Package >>dependency ! >> >> >> >>So TDEPENDS is not a denormalization of DEPENDS + package installed, it's >>a different type of relationship. >> >> >>Hope this helps, >>Alex >> >> >> >> >> >> >>On Thu, Jan 16, 2014 at 5:02 PM, Lerner, Dave >><[email protected]> wrote: >> >>Hi Belen, Alex >> >>1) I assume the same arguments for RRECOMMENDS and TRRECOMMENDS as for >>RDEPENDS and TRDEPENDS, right? >> >>2) Do we update the spec in this case? >> >>3) We're encoding two attributes of a relation into one field: >> dep_type = (dependency type + builtOrInstalled) >>instead of splitting >> dep_type= dependency type >> installed = true|false >>This is an optimization maybe, but not normalized. Is that ok? >> >>-Dave >> >>> -----Original Message----- >>> From: Barros Pena, Belen [mailto:[email protected]] >>> Sent: Thursday, January 16, 2014 10:46 AM >>> To: Lerner, Dave; Damian, Alexandru >>> Cc: Eggleton, Paul; [email protected] >>> Subject: Re: TRDEPENDS, TRRECOMENDS vs RDEPENDS, RRECOMENDS >>> >>> >>> >>> On 16/01/2014 16:34, "Lerner, Dave" <[email protected]> wrote: >>> >>> >Hi Belen, Alex >>> > >>> >Alex wrote: >>> >> Thus we collect the package information two times: once when the >>> >>package is build, and >>> >> once when the package is installed on the target. >>> >> Note that these two sets may not be identical, as on target install >>>we >>> >>collect data for >>> >> a different set of packages that what was actually built during the >>> >>current run. >>> > >>> >While the sets may not be identical, the dependency relation between >>> >packages should not change based on whether the package was from a >>> >previous build or from sstate. >>> >>> Oh, good, this is back! ;) Paul, Alex and I have had numerous >>>discussions >>> about this issue, and if I remember correctly, our latest conclusion >>>was: >>> >>> If a package is not installed in any target: >>> >>> * package-built-details page shows RDEPENDS >>> * package-installed-details page does not exist for such package >>> >>> If a package is installed in a target: >>> >>> * package-built-details page shows nothing, it is just a link to the >>> package-installed-details page >>> * package-installed-details page shows TRDEPENDS >>> >>> Why? 2 reasons: >>> >>> 1. Because usually RDEPENDS and TRDEPENDS will be the same >>> 2. Because we are working on the assumption that what matters to the >>>vast >>> majority of people is the information about the installed packages >>>(what >>> matters to me is the image that comes out of the build process, and not >>>so >>> much the build process itself). >>> >>> I could have understood wrong though, or we might decide that the above >>>is >>> no longer good enough. >>> >>> Belén >>> >>> >>> > >>> >So, I would think the list of RDEPENDS to view always shows RDEPENDS >>>and >>> >TRDEPENDS, whether a package was built, or pulled from sstate cache. >>> > >>> >Comments? >>> >Dave >>> > >>> >> -----Original Message----- >>> >> From: Damian, Alexandru [mailto:[email protected]] >>> >> Sent: Thursday, January 16, 2014 10:04 AM >>> >> To: Lerner, Dave >>> >> Cc: Eggleton, Paul ([email protected]); >>[email protected] >>> >> Subject: Re: TRDEPENDS, TRRECOMENDS vs RDEPENDS, RRECOMENDS >>> >> >>> >> Hi, >>> >> >>> >> >>> >> This is an artifact of how data is collected. >>> >> >>> >> >>> >> TRDEPENDS and TRECOMMENDS are just RDEPENDS and RRECOMMENDS >>>collected >>> >>at target creation >>> >> time, instead of package build time. >>> >> >>> >> >>> >> What may happen is that for a target we use packages that were not >>> >>built during the >>> >> current build, but either in a previous build or reused from sstate >>> >>cache. >>> >> >>> >> Thus we collect the package information two times: once when the >>> >>package is build, and >>> >> once when the package is installed on the target. >>> >> Note that these two sets may not be identical, as on target install >>>we >>> >>collect data for >>> >> a different set of packages that what was actually built during the >>> >>current run. >>> >> >>> >> >>> >> I suggest that in "target install packages" page we show the T* >>> >>dependencies, and in the >>> >> "build packages" page we should the non-T dependencies. >>> >> >>> >> >>> >> Hope this helps, >>> >> Alex >>> >> >>> >> >>> >> >>> >> >>> >> On Wed, Jan 15, 2014 at 6:20 PM, Lerner, Dave >>> >><[email protected]> wrote: >>> >> >>> >> >>> >> Hi Paul, Alex >>> >> >>> >> I have a question on inserts into the package_dependency and >>> >> target_installed_package. >>> >> >>> >> I would expect that for the following builds and sato in >>>particular: >>> >> {core-image-minimal, qemux86} >>> >> {core-image-minimal, qemux86} >>> >> {core-image-sato, qemux86} >>> >> {[core-image-minimal,core-image-base], genericx86} >>> >> that there would be a few installed packages with some package >>> >>dependencies like >>> >> (RDEPENDS, RRECOMENDS), but that isn't the case. The only >>>dependencies >>> >>for installed >>> >> packages are TRDEPENDS or TRRECOMMENDS. >>> >> >>> >> SELECT PkgS.name, PkgT.name dependsOn, PkgDep.dep_type >>> >> FROM orm_package PkgS, >>> >> orm_package_dependency PkgDep, >>> >> orm_package PkgT, >>> >> orm_target_installed_package Inst >>> >> WHERE >>> >> PkgS.id = PkgDep.package_id >>> >> AND PkgT.id = PkgDep.depends_on_id >>> >> AND Inst.package_id = PkgS.id >>> >> AND Inst.package_id = PkgDep.package_id >>> >> AND Inst.target_id = PkgDep.target_id >>> >> ; >>> >> name|dependsOn|dep_type >>> >> update-rc.d|busybox|6 >>> >> sysvinit-inittab|busybox|6 >>> >> libc6|busybox|6 >>> >> libc6|libc6|6 >>> >> packagegroup-core-boot|base-files|6 >>> >> packagegroup-core-boot|base-passwd|6 >>> >> ... >>> >> (more) >>> >> >>> >> adding a filter to the above to filter out the "T..." types >>> >> AND PkgDep.dep_type < 6 >>> >> returns an empty set. >>> >> >>> >> What is the meaning of TRDDEPENDS and TRRECOMMENDs and do the >>>results >>> >>seem correct? >>> >> >>> >> Thanks >>> >> Dave >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> -- >>> >> >>> >> Alex Damian >>> >> Yocto Project >>> >> >>> >> SSG / OTC >>> >> >> >> >> >> >> >> >> >> >>-- >>Alex Damian >>Yocto Project >> >>SSG / OTC >> >> > >_______________________________________________ >toaster mailing list >[email protected] >https://lists.yoctoproject.org/listinfo/toaster _______________________________________________ toaster mailing list [email protected] https://lists.yoctoproject.org/listinfo/toaster
