[oi-dev] Userland dev, Zone and processes

[Jim Klimov]

5 февраля 2016 г. 1:48:27 CET, bentahyr at chez.com пишет:
>Hi,
>
>I created a zone with oi-userland dev and tools and I finally made my 2
>first packages.
>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
>zone.
>Adding publisher is ok but when I issue the pkg install command I get :
>
>-pkg install: Invalid child image publisher configuration.  Child image
>publisher
>-configuration must be a superset of the parent image publisher
>configuration.
>-Please update the child publisher configuration to match the parent. 
>If the
>-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 ?
>
>Best regards.
>Ben
>
>_______________________________________________
>oi-dev mailing list
>oi-dev at openindiana.org
>http://openindiana.org/mailman/listinfo/oi-dev

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.

good luck,
Jim
--
Typos courtesy of K-9 Mail on my Samsung Android