> I am making a change on a client package that will use a library that is > being packaged along with the corresponding server package. I would > like to also move the library to be packaged in the client package > instead of the server package. Regardless of where the library is > being packaged, after I build my workspace, I noticed that there is a > cyclic package dependency which seems to cause a problem with > uninstalling either package since IPS shows that the client package > depends on the server package and vice versa.
It sounds like there are at least four valid dependencies: 1. something in the server package depends on the library 2. something in the client package depends on the library 3. something in the server package depends on something else (not the library) in the client package 4. something in the client package depends on something else (not the library) in the server package Because of 3 and 4, it doesn't matter where the library is packaged. > I am unable to find documentation to make the server packages depends on > the client package only and not have the client package depends on the > server package in this situation. The server dependency on the client > package is automatically generated from the build process. Is there a > way to explicitly state that the client package should not depend on the > server package? I don't think you want to do that. If the dependency is automatically detected at build time, then it is real, and should not be suppressed. The only problem with cyclic dependencies is that you can't (as you said above) install only one of the two packages. Otherwise, it's harmless. If you want to be able to install only one of the packages, then you need to figure out the nature of the other dependencies. You can do this after you build your packages by looking for lines that start with "depend fmri=__TBD" in usr/src/pkg/packages.$ARCH/pkgname.dep. The pkg.debug.depend.file attribute will name the dependency, and the pkg.debug.depend.reason attribute will name the file in the current package that causes the dependency. I don't know what the build will do if you name the library in each package manifest, but if it doesn't fail, it could also cause circular dependencies. --Mark _______________________________________________ on-ips-dev mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/on-ips-dev
