Ok, that makes sense. I'll implement those changes.
-dave

> -----Original Message-----
> From: Damian, Alexandru [mailto:[email protected]]
> Sent: Thursday, January 16, 2014 11:26 AM
> To: Lerner, Dave
> Cc: Barros Pena, Belen; Eggleton, Paul; [email protected]
> Subject: Re: TRDEPENDS, TRRECOMENDS vs RDEPENDS, RRECOMENDS
> 
> 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

Reply via email to