On 09/01/11 08:58, Jiri Sasek wrote:
On 09/ 1/11 04:09 PM, Alan Coopersmith wrote:
On 09/01/11 03:12, Jiri Sasek - Solaris Prague wrote:
root@v210a:~# pkg contents -r -m userland-incorporation | grep -i samba
depend facet.version-lock.service/network/samba=true
fmri=pkg:/service/network/[email protected] type=incorporate
depend facet.version-lock.library/samba/libsmbclient=true
fmri=pkg:/library/samba/[email protected] type=incorporate
root@v210a:~#
...but I am not guru to understand what the "facet..." really mens.
It means that if you install userland-incorporation, the
depend type=incorporate constraint on the versions of
pkg:/service/network/samba that you can install will be
honored if facet.version-lock.service/network/samba=true
and ignored if it is false. By default all facets are true.
The constraint will only allow you to install versions matching
the pattern 3.5.10-0.172, which could include 3.5.10.1-0.172,
3.5.10-0.172.0.0.0.0, etc. as only the portions of the version
specified need to match.
It looks like a facility to lock the bug-fix only branch against the install of
the new releases. Am I right?
You mean incorporations? They're a way to deliver a known set of
packages together. The way we use them is based on the way we've
traditionally built and delivered Solaris - a biweekly build
consisting of the deliveries from a set of consolidations that were
all tested together.
The 'entire' incorporation defines the biweekly build. You can
remove entire if you want to allow different consolidations to
be at different build levels, say if you're testing an update to
one of them. It's there by default though so you have to opt-out
of being on a supported/tested combination and move onto a custom
path that only you have tested. (Designing for customer systems,
with developers having to do more work.)
Before build 172, userland packages weren't in any incorporation,
so you could change their versions more freely, though still
constrained by dependencies in other packages. This is why, as
you may have seen, 'pkg install [email protected]' wasn't working - it
would upgrade all the incorporated packages to the build 170
versions, but userland ones would be left out - adding the userland
incorporation should fix that, so you can install a specific build.
(Right now, for us, "specific build" is a development biweekly build - in
the customer world, it will be something like "the S11 SRU your
company standardized on for all production systems for this quarter",
even if the repo has newer SRU's you may be testing for the next
round of deployment on your test systems.)
There is a recognition though, that not all packages are as intrinsically
interrelated as others - ON packages have lots of private interfaces where
both sides need to be upgrade in sync. For instance, if you change the
system calls, then the kernel, libc, truss, dtrace, etc. need to be in
sync. But if you are applying a bug fix to the mutt mail client, that
likely doesn't need any more synchronization with the rest of the userland
consolidation packages than that provided by the version dependencies
automatically added by pkgdepend for the tools & libraries it depends on.
So facet.version-lock.<package-name> was added to allow opting out of
individual package versions - it's not on all packages in all incorporations,
just those believed to be useful & safe to be more flexible. I believe
X, JDS, CDE, & Userland consolidations apply it to all packages, while ON only
offers it on a handful.
So did that answer your question, or did I misunderstand what you're asking?
--
-Alan Coopersmith- [email protected]
Oracle Solaris Platform Engineering: X Window System
_______________________________________________
userland-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/userland-discuss
