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.
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).
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.
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.
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?
Thanks,
Hoa
_______________________________________________
on-ips-dev mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/on-ips-dev
