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. 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
