Liane Praza wrote:
Any takers for a quick final check of the changes?
http://cr.opensolaris.org/~lianep/pkg-gate/
s/Depedencies/Dependencies/
I'd check with David on whether he's okay with the new name.
From a corridor conversation yesterday, I think it's okay with him.
The last part doesn't clash with any existing package name. :-)
Liane Praza wrote:
Danek Duvall wrote:
On Tue, Mar 31, 2009 at 10:54:33AM -0700, Liane Praza wrote:
http://cr.opensolaris.org/~lianep/pkg-gate/
Looks fine, but two suggestions:
I chatted with Danek and a few others about this. Capturing the
discussion here for future reference. Feel free to proceed directly
to the re-review, which is updated in place at the link above.
- You might want to consider putting the package into entire, as
well,
which would imply putting a dependency on it into redistributable,
which is also in redist_cluster. Right now, this will mostly
prevent
people from getting a message about violated constraints if they
try to
upgrade the package when its dependencies can't move forward.
The big point of agreement is that the same policy should apply to
both this package and the existing SUNWonbld. Both are support
packages which should be delivered with a build and represent the
state of the build environment for that build (e.g. sunwon...@111
should be the bits needed to build the 111 snapshot for ON).
However, for developers, it's desirable that they can move SUNWonbld
and the new package forwards faster if they desire (e.g. when ON
updates webrev in build 112, but build 112 isn't available as part of
the standard dev repo yet, possibly simply because the build hasn't
yet closed).
This could be addressed in a few different ways:
1) Ideally, SUNWonbld would always be built on the oldest supported
build for compiling ON, have dependencies on the package versions it
was built with, and would be in its own incorporation with the new
package to let them move forward independently of the rest of the
system. I'm not pursuing this one now, because it doesn't reflect
the reality of how SUNWonbld is built today and I'm not looking to
start down the path of creating multiple incorporations just yet.
2) Don't incorporate SUNWonbld or the new package into entire.
Unconstrain the dependencies to @0 so that any version of the
dependency can be used. Then new versions of the packages can be
distributed from anywhere, with any updated version, as long as they
keep the dependencies unconstrained so that they don't run into the
problem Danek mentioned. (This would require some re-engineering for
the automatically determined dependencies for SUNWonbld.)
3) Incorporate SUNWonbld and the new package into entire. If updates
are needed, they'll need to be published with the version of entire
they're expected to work with, e.g. @-0.111.01 and appropriate
dependencies.
I've chosen #3 for now. We might want to change this when there's a
regular ON development repo being published (yes, working on it) so
that fiddling with version numbers isn't required, but #3 seems like
the most appropriate choice given where we are today.
- I'd like to use "osnet" as the ON handle in package names. I'm
thinking the package name here could be "developer/cbe/osnet".
After talking to or corresponding with pretty much everyone, I'm
going to go with developer/opensolaris/osnet. If we come up with
something better during the big rename (or when contemplating the new
name for SUNWonbld), it can always be changed.
liane
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
