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
