5 февраля 2016 г. 1:48:27 CET, [email protected] пишет: >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 >[email protected] >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 _______________________________________________ oi-dev mailing list [email protected] http://openindiana.org/mailman/listinfo/oi-dev
