On Wed, Jan 22, 2014 at 12:18 PM, Michael K. Johnson <[email protected]> wrote: > On Wed, Jan 22, 2014 at 11:05:59AM +0100, Mark Trompell wrote: >> > What does conary do with rpms? Basically conary picks up the rpm from a >> > location. Explodes it. Gathers all the file paths and figures out deps >> > from the files. Conary then throws the files away and packs the rpm in the >> > conary package. >> >> How does it handle scripts, like shown with qpm -q --scripts > > Conary hands the RPM packages to RPM, and RPM runs the RPM scripts. > > I don't recall off the top of my head whether encapsulated files > can additionally be tagged to run tag scripts, but there would > not normally be any point in doing so. > > The encapsulating conary package can have native components as > well as encapsulated components. > > $ conary rq --troves --all-troves --trove-flags > rpm=centos6.rpath.com@rpath:centos-6e --config 'repositoryMap > centos6.rpath.com https://updates.sas.com/conary/' > rpm=4.8.0_37.el6-2-1 > rpm:debuginfo=4.8.0_37.el6-2-1 [NotByDefault] > rpm:python=4.8.0_37.el6-2-1 > rpm:rpm=4.8.0_37.el6-2-1 > > The rpm:rpm component is the actual encapsulated RPM package > of RPM that Conary hands off to RPM to install.
Ok, I think I start to understand the whole thing a bit better now. But would conary verify still work? what would a conary q foo --lsl show? > The rpm:python component is a native conary component, built > against the rpm sources and against the same version of Python > that Conary is built against. Right now, that CentOS import > has a separate python stack for Conary to reduce its exposure > to platform bugs; a decision that was made back at rPath for > a variety of reasons that don't really apply now. Later, we > do expect to migrate the Conary in that import to use system > Python instead, both to reduce image size and to make it easier > to "adopt" installed systems. For our F20 import, we'll make > the same choice and use the system Python. Therefore, we will > not have that "rpm:python" component in our import. > >> Will it map eg. foo-devel to foo:devel? > > $ conary rq --troves --all-troves --trove-flags > rpm-devel=centos6.rpath.com@rpath:centos-6e --config 'repositoryMap > centos6.rpath.com https://updates.sas.com/conary/' > rpm-devel=4.8.0_37.el6-2-1 > rpm-devel:rpm=4.8.0_37.el6-2-1 > > No. That's a policy decision to make it easier to map RPM > dependencies to conary packages. > > At rPath, before we implemented encapsulation, we had what we > called "binary import" which was what I suggested for "Boots" > oh so many years ago. In that model, we pulled in sets of > packages grouped by SRPM and did map foo-devel to foo:devel > but I don't think that makes sense for a pure encapsulated > import. > > If, after we import F20 as an encapsulated import, someone is > interested in using that encapsulated platform to bootstrap > either a "binary import" as I previously suggested for Boots > or an automated source rebuild as we have discussed at other > times, they would almost certainly want to do that mapping; > the question then would be whether to do the mapping at all > or to let Conary policy map to components and explicitly > override that when policy didn't do what you wanted; it would > really depend on how much time those people wanted to spend. > Right now, I can't see that I have the time to do that work, > much as I would (as an inventor of many of those concepts) > like to see it work. > > _______________________________________________ > Foresight-devel mailing list > [email protected] > https://lists.foresightlinux.org/mailman/listinfo/foresight-devel > -- Mark Trompell Foresight Linux Xfce Edition Cause your desktop should be freaking cool (and Xfce) _______________________________________________ Foresight-devel mailing list [email protected] https://lists.foresightlinux.org/mailman/listinfo/foresight-devel
