On 02/14/13 12:06 PM, Erik Trauschke wrote:
On 12/19/12 11:48 AM, Tim Foster wrote:
So this updated webrev does the following renames (omitting module
renames in src/tests here):
src/http-depot.py -> src/depot-config.py
src/svc/pkg-http-depot.xml -> src/svc/pkg-depot.xml
src/svc/svc-pkg-http-depot -> src/svc/svc-pkg-depot
src/pkg/manifests/package:pkg:http-depot.p5m
-> src/pkg/manifests/package:pkg:depot.p5m
src/svc/svc-pkg-depot -> src/svc/svc-pkg-server
I just discovered a problem with this name change when trying to install
a new depot server version on an older (s11u1) machine using the
pkg_root property.
Since the old SMF manifest still uses the svc-pkg-depot method for the
pkg.depotd server the service is trying to start the http depot in the
environment specified by pkg_root.
Ok, I didn't know how pkg_root works - offline Eric told me that it
points to an environment containing new pkg(5) bits.
I'm not sure if this is a big enough issue to fix but it will break the
ability to run a depot server from after this changeset on a machine
running bits from before.
This sounds like an intentional case of requiring compatibility between
the OS-specified SMF service, and the SMF service (and method)
delivering the new bits in pkg_root, since the OS version of the
pkg/server method script expects that:
exec='%{pkg/pkg_root}/lib/svc/method/svc-pkg-depot %m'
does the right thing, and on systems where 'svc-pkg-depot' starts
pkg.depotd usually, but in new pkg(1) bits runs the Apache-based depot,
that's going to cause some confusion alright.
I'm not sure there's anything we can do here, other than recommend to
the user to modify the SMF manifest in the new pkg(5) bits to change the
service name, and then start that service. Since we don't really
document pkg_root, I expect this is something customers aren't likely to
ever need to do.
cheers,
tim
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
