[Toaster] TRDEPENDS, TRRECOMENDS vs RDEPENDS, RRECOMENDS
Barros Pena, Belen
belen.barros.pena at intel.com
Fri Jan 17 06:13:12 PST 2014
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.
Questions, comments, suggestions, general wonderments?
Thanks!
Belén
On 16/01/2014 17:26, "Damian, Alexandru" <alexandru.damian at intel.com>
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
><dave.lerner at windriver.com> 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:belen.barros.pena at intel.com]
>> Sent: Thursday, January 16, 2014 10:46 AM
>> To: Lerner, Dave; Damian, Alexandru
>> Cc: Eggleton, Paul; toaster at yoctoproject.org
>> Subject: Re: TRDEPENDS, TRRECOMENDS vs RDEPENDS, RRECOMENDS
>>
>>
>>
>> On 16/01/2014 16:34, "Lerner, Dave" <dave.lerner at windriver.com> 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:alexandru.damian at intel.com]
>> >> Sent: Thursday, January 16, 2014 10:04 AM
>> >> To: Lerner, Dave
>> >> Cc: Eggleton, Paul (paul.eggleton at intel.com);
>toaster at yoctoproject.org
>> >> 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
>> >><dave.lerner at windriver.com> 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
>
>
More information about the toaster
mailing list