[oi-dev] [HEADS UP] Userland incorporation

[Alexander Pyhalov]

Hi.

On 10/09/2015 09:06, Nikola M wrote:
> On 10/ 4/15 07:37 PM, Alexander Pyhalov wrote:
>> The following concerns OI Hipster users. Now entire is not empty, but
>> depends on userland incorporation, which is created by Jenkins
>> automatically.
>> Userland incorporation (consolidation/userland/userland-incorporation)
>> includes incorporate dependencies on highest package versions in
>> Jenkins repository. As illumos-gate and kvm are published by separate
>> Jenkins job, they are not included in incorporation.
>>
>> So, if you want install other package versions, you can set
>> corresponding facets in your image or remove entire and
>> userland-incorporation packages.
>
> Great,
> Isn't the point of 'entire' to also depend on illumos-gate version and kvm?
>

No. I don't want to speak about entire "point", but
a) I don't want to incorporate llumos-gate versions and tie them to 
userland versions. Doing so we'll make illumos developers life harder, 
and it's I think most valuable OI users.
b) We already have osnet incorporation and you use it in the same way. 
Entire depending on osnet doesn't make any sense as you can't install 
system without installing osnet.

> So that user can set exact state of all system at a present time if
> testing for regressions?

You can do it choosing necessary userland incorporation date and osnet 
incorporation date.

> it is step in right direction so to say.
>
> But I have some questions:
> I am still not understanding how to figure what package is part of what
> incorporation?

The following consolidations are used to build 	 OI Hipster:
illumos-gate - the base system packages constrained by osnet-incorporation,
oi-userland, the main one, everything besides Solaris-derived specific 
software should live here, packages are constrained by 
userland-incorporation,
slim_source - installer, packages are constrained by install-incorporation,
pkg5 - IPS.

So, if it's not installer or IPS or base package, it belongs to oi-uselrand.

> There are many logical incorporations in Hipster yet they are empty?
> Is illumos-gate in osnet-incorporation and that's it?
There are a lot of incorporations. Part of them are useless, as these 
are binary packages derived from OpenSolaris, which are unlikely to be 
modified. The only incorporations which make sense are 
osnet-incorporation, install-incorporation and now userland-incorporation.


> Why there are incorporations when they are empty? And why they are
> emptied? Why say gnome-incorporation is empty etc.
> If illumos-gate uses incorporations when publishing packages, what are
> they?
osnet-incorporation.

There are 2 choices we could do: deprecate incorporations or make them 
empty. As there are chances that some exotic software still depends on 
them, we provide empty incorporations. Perhaps this can be changed and 
empty incorporations could be just marked as obsolete.

>
> When Jenkins is is updating illumos-gate or some package is updated in
> oi-userland, why when changes are selected to view, they are mixed in
> jenkins, so illumos-gate change and oi-userland changes display same
> changes?

Because illumos-gate Jenkins instance monitors oi-userland and uses 
oi-userland component to build illumos-gate. In fact, it is oi-userland 
job, just tuned to build only illumos-gate and kvm packages.

> I pretty much dont' understand Hipster layout.
>
> Where and how changes in OI Hipster are announced? And where are they
> made available before actually making changes, since I see changes in
> hipster just appear and are published without previously knowing about it?
> Is there some sort of planning page where people can announce what they
> are working on and what they plan to integrate and when?

There's IRC and mailing list. You can always create pull request and we 
will integrate it after review.

>
> There is also question of backing down package versions to previous
> versions if new one didn't work/passed testing. Currently as Iknow there
> is no way to get back to the system state with previous package version
> after updating package version.
> Isn't that is what comlicated package version names on the left side of
> version number were about, to enable changing package version number and
> have real upstream package number coming after that as an info?

No, it was about creating numbering scheme which would allow to take 
into account component revision and different release numbers. It 
doesn't allow to downgrade package. I have mixed feeling about hiding 
actual package versions behind release numbers and of course don't want 
to change current scheme without serious reasons.

-- 
Best regards,
Alexander Pyhalov,
system administrator of Southern Federal University IT department