[oi-dev] Userland dev, Zone and processes
jimklimov at cos.ru
Fri Feb 5 20:04:51 UTC 2016
5 февраля 2016 г. 1:48:27 CET, bentahyr at chez.com пишет:
>I created a zone with oi-userland dev and tools and I finally made my 2
>I gave up on cloning the dev zone (zoneadm clone doesn't work) to try
>to install the package and relied VBox as I don't need much power to
>test the package.
>Now I would like to install these packages on my dev zone so I can work
>on a third package depending on the 2 first ones but here I am with a
>new issue. I can't seem to add publisher and use packages from my dev
>Adding publisher is ok but when I issue the pkg install command I get :
>-pkg install: Invalid child image publisher configuration. Child image
>-configuration must be a superset of the parent image publisher
>-Please update the child publisher configuration to match the parent.
>-child image is a zone this can be done automatically by detaching and
>-attaching the zone.
>-The parent image has the following enabled publishers:
>- PUBLISHER 0: openindiana.org
>- PUBLISHER 1: hipster-encumbered
>-The child image has the following enabled publishers:
>- PUBLISHER 0: userland
>- PUBLISHER 1: openindiana.org
>- PUBLISHER 2: hipster-encumbered
>- PUBLISHER 3: localhostoih
>So I was wondering what am I doing wrong in the zone as it seems IPS is
>highly tighten to the global zone. Is there a more independent way to
>set the zone ?
>Second question is what should be the process to add new packages to
>userland on github ?
>- open feature request on OI bug tracker ?
>- pull request on github oi-userland repo ?
>- mail to oi-dev ?
>oi-dev mailing list
>oi-dev at openindiana.org
regarding zone-cloning: seems like a bug, should be clonable. at worst you can manually snapshot and clone the zone's datasets and replicate the configuration in GZ /etc/zones/zonename.xml files and index listing there.
consider 'nlipkg' zone brand (IIRC) which is same as ipkg but unties these publisher requirements.
procedure is gihubish - fork the repo, on github, clone your fork to your workstation, optionally make a branch for the new piece of work, develop, push back, make a PR against OpenJ diana/oi-userland, and prepare for discussions. Usually it boils down to common-style formality, sometimes suggestions on recipe implementation detail, and in the end you'd rebase so the changeset is one commit.
Typos courtesy of K-9 Mail on my Samsung Android
More information about the oi-dev