That's too long winded for me Alan.

Start with an executive summary:

Do this:
   blah blah

If you just know:
   blah

craig

----- [email protected] wrote:

> On 06/ 6/11 05:18 PM, Alan Coopersmith wrote:
> > I believe that this won't require any sort of flag day, just
> coordinated
> > putback to both consolidations in the same build (hopefully in
> 169).
> > 
> > Those who update to on-nightly but not userland-nightly would simply
> see
> > hardware-registry become unconstrained by osnet-incorporation, but
> the
> > package dependency in the hal package would keep the installed copy
> around.
> 
> There was one wrinkle I overlooked, seems best handled by a flag day
> message.
> While this particular package is not likely to cause any problems,
> I've
> tried to give enough background to help with future similar cases.
> 
> Does the following sound good to everyone?   Or is it too long and
> overly
> detalied?
> 
>      -alan-
> 
> The putback of "7052095 pkg:/system/data/hardware-registry should be
> removed
> from ON consolidation" constitutes a small flag day for developers and
> testers
> installing packages from on-nightly or similar ON development/project
> gate
> repos.
> 
> This putback, paired with "7016849 pkg:/system/data/hardware-registry
> should
> move to Userland consolidation" moves the hardware-registry package
> from the
> ON gate to the Userland gate.
> 
> This package provides the pci.ids & usb.ids files /usr/share/hwdata
> to
> map PCI & USB vendor & device ID's to human readable/marketing names.
> This data is used by commands such as hald, DDU, scanpci and Xorg to
> identify the devices in your system.
> 
> Since the same package is now provided by a different consolidation,
> it will no longer be provided by the on-nightly or similar publisher,
> but for most users will come from the solaris publisher with the rest
> of the WOS.  (Unless you happen to be doing Userland
> development/testing
> and get it from the userland publisher instead.)  However, the pkg
> system
> will only replace an installed package with one from a different
> publisher
> if the publisher is marked non-sticky - much as you have to mark the
> solaris publisher non-sticky in order to replace the ON packages when
> installing an on-nightly build.
> 
> If you only install full Solaris WOS builds from the solaris
> publisher,
> then there's nothing you need to do.   The hardware-registry package
> will always simply come from the solaris publisher.
> 
> If you haven't installed the ON packages from a publisher other than
> the solaris publisher prior to this change, again there is nothing
> you
> will need to do.  When you first install an on-nightly build, it will
> not replace the hardware-registry package provided by the solaris
> publisher, and future upgrades will follow the solaris publisher
> version.
> 
> If you have already updated to packages from an ON-specific publisher
> that were built prior to this changeset, then future upgrades will
> leave
> the existing hardware-registry package from the last on-nightly build
> you installed with it in, and you will not get future versions in
> upgrades.  To allow upgrades to replace the existing ON package with
> new versions from the solaris publisher, you will need to mark the
> on-nightly (or equivalent) publisher as non-sticky:
> 
>       pkg set-publisher --non-sticky on-nightly
> 
> Of course, should you fail to do this, in this particular case, the
> effect will simply be that you don't get new names for new devices
> nor the occasional updates/corrections to existing devices, which is
> unlikely to cause any actual issues with the system.   Future cases
> of packages moving from ON to other consolidations may have more
> impact, depending on the packages in question.
> 
> -- 
>       -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
_______________________________________________
on-ips-dev mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/on-ips-dev

Reply via email to