On Thu, Jan 30, 2014 at 07:06:00AM -0500, Michael K. Johnson wrote: > Basically, all the rpm: requires in the conary packages that > encapsulate RPMs need to be satisfied by rpm: provides in those > conary packages. And the only way to get rpm: provides and requires > is to encapsulate an RPM, one way or another. > > So, you have a choice: > > * Replace libfoo with a Conary native package, and replace EVERY > encapsulated package that depends on libfoo with a Conary native > package as well. > > * Replace libfoo with an RPM sourced from somewhere else; say, > pulling in libfoo from rawhide and adding the encapsulated > package to fl3. > > * Use Conary to call rpmbuild to build an RPM from source and > encapsulate the output of that build. > > * Use Conary to build an empty libfoo RPM as part of building a > native conary libfoo package, and make the libfoo:rpm component > depend on the libfoo:lib component in that package.
One other thing we had discussed long ago (back when we were calling a similar proposal "boots") was not enforcing rpm class dependencies in Conary within a foresight based on such an import. The reason I was not proposing that now is that this depended on full conary dependency discovery, including python: and perl: dependencies, and that's fragile across changes to the underlying packages. Also, we are assuming that the dependencies in the RPM packages are now better specified than they were previously. So I should explicitly withdraw my previous idea of not enforcing the rpm dependency class in Conary in FL3. There is at least one more real choice, though: * Adding a foresight-specific policy that allows you to mark a package as an RPM replacement, allowing it to provide dependencies in the rpm dependency class without actually holding encapsulated RPMs. The potential downside is that if there are some hidden dependencies within Fedora on RPM's package installation ordering or the RPM scripts attached to a package, doing so might introduce bugs. That's probably unlikely. It might also introduce either bugs or reasonably undefined behavior in Conary's interface with RPM for installing encapsulated files, since it was not a use case that was considered when that was being designed. That would have to be a "try it and see" case. Fortunately, it would be possible to test it prior to baking it into FL3... _______________________________________________ Foresight-devel mailing list [email protected] https://lists.foresightlinux.org/mailman/listinfo/foresight-devel
