On 06/29/10 12:58 PM, Evan Layton wrote:
Details of 16408:
The install-incorporation manifest in slim_source needs to match what
was previously handled by RE and the importer; which means the
obsolete/renamed packages need to be included, as well as some
additional packages that are tagged under install-incorporation (such
as python/lxml). As a short term fix, I've explicitly added them to
the manifest file; long term it would be more consistent for our gate
to build the empty, renamed packages (to catch the cases of upgrading
from a built copy of our gate, and for tracking purpose) - but for
expediency's sake I'd like to defer that and lump it with changes to
our gate to fully remove the SVR4 packages.
I noticed that the FMRI you specified included build numbers. Does
that mean you will
have to update this file for every build? Can we omit the build
numbers so the latest
will get pick up?
The build numbers for the renamed packages are permanently at 133 - that
won't change with each build. The build numbers for
developer/dtrace/toolkit, library/python-2/lxml-24 and lxml-26 I've set
to 142 based on emails with David Comay (note that they'd need to be at
143 for this build, for example; and if they needed to be dynamically
set that would be simple enough to do).
I'm a bit confused here still...
These first three packages are post package renaming so why don't we
want to set the build number dynamically for these packages?
depend fmri=developer/dtrace/[email protected] type=incorporate
depend fmri=library/python-2/[email protected] type=incorporate
depend fmri=library/python-2/[email protected] type=incorporate
I'm not entirely certain of the reason here, to be honest. I'm updating
the incorporation as asked by Comay. He said that they should be tagged
at 142, instead of dynamically (note that if they were dynamic, they'd
be getting set to 143 at present - see Makefile.buildnum in the gate
tip); I believe that it has to do with the fact that we don't actively
deliver those packages with the rest of our install packages.
Is this also one of the things that will be changed longer term when
we finish fully removing the SVR4 package stuff?
If I find out it needs to change later, that can certainly be done. My
current understanding of it is that those packages will be stuck under
our incorporation, as listed, until we find a better place for them.
Thanks for reviewing!
- Keith
Thanks!
-evan
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
