On 01/ 3/11 08:09 PM, Hoa Nguyen wrote: > On 01/ 3/11 06:13 PM, Mark J. Nelson wrote: >>> 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. >> > > Prior to my changes, the server already depends on the client package > and the server package is using that library. And the client does not > depend on the server package. Once that library is changed to be a > common library for the server and client, the circular dependency resulted.
This is dependency number 3 above. >>> 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. >> > > My problem is uninstalling the server if both are installed but the > installing issue is also interesting. > > Yes, the circular dependency issue doesn't seem to cause a functional > problem other than someone wanting to uninstall the server and then the > client (in this order). Order won't matter. >> 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. >> >> > This was discussed but was not sure if the library should be packaged in > both packages. I was hoping that by moving the common library to the > client package then the client will not depend on the server package. To clarify: the library may not be packaged in both packages. I was not suggesting that you should try that, I was merely speculating on what might cause the dependencies you're seeing. > So it seems there is no way to explicitly state that a package should > not have a dependency on another and we should not suppress them if the > dependency is detected. Correct. > I'll take a look at the files you mentioned to see if there is something > in the server package that the client is depending on eventhough the > common library is moved to the client package. So if the moved common > library still depends on something in the server package then the > client's dependency on the server is created right? Right. > Thanks, > Hoa _______________________________________________ on-ips-dev mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/on-ips-dev
