[oi-dev] OpenIndiana /hipster build number

Mon Jan 13 08:34:14 UTC 2014

On 9 January 2014 23:06, Alexander Pyhalov <alp at rsu.ru> wrote:

> 1) When new repository is created? Once a quarter? When old one is too big?

At least once a year I think. It will be up to us/devs when to create
new repo based on the old repo's size or any other condition.

> 2) What packages are migrated to the new repository?  The latest versions of
> every package in the last active repository?

Yes,  The latest versions of packages in the last active repository,
but only installable ones. If some packages were obsoleted, we skip
them. Same with the renamed packages.

> 3) How do we migrate user systems to new repository, let's say from
> pkg.openindiana.org/hipster to pkg.openindiana.org/hipster-2014.0 and
> further to pkg.openindiana.org/hipster-2014.1 ?
> Some self-destructing SMF? We clearly have to force new BE creation on such
> shift.

After creating new repo, we would upload modded pkg5 to the old repo.
It could emit a message with instructions on what to do to switch the
repos on "pkg update". Users would be expected to have their systems
fully upgraded before switching the repos. I don't think messing with
people's publisher configuration would be a good thing to do.

> As for spped of operations on current repository, is it possible to change
> "pkgrepo rebuild" to "pkgrepo refresh" in Jenkins build jobs? Is it safe? Is
> speedup significant?

We are currently using old-school pkg.depotd --add-content whcih is
fairy quick (it takes minutes). pkg.depotd --rebuild takes 1-2h on the
current repo. Package server is running quite old version of pkg5. I
am not sure pkgrepo refresh is supported by it at all. Long term I
would like to server OI hipster package with newer pkg5 bits but
didn't have a chance to look at it yet.

> Now, about versioning scheme.
> 1) I still don't see a clean way to downgrade package with proposed
> versioning scheme.

I don't think it is possible to perform automatic downgrades with pkg5
in general. Not sure if anything has changed in this regard in the
updated pkg5 code.

> 2) What is a policy for changing PKGREV_COMPONENT? I propose to set it to 0
> by default and force people to increment it with every change in a component
> which affects its functionality (i.e., not just code cleanup). I would reset
> it to 0 with every package version bump (e.g. php 5.21=> php 5.22), this
> will allow us to keep it sane. And I'm not sure that it is a good idea to
> use it just to force package rebuild.

I 100% agree with what you described.

> 3) What will we do with illumos-gate updates? I mean, proposed scheme allows
> us to do it in a safe way. However, when build machine is updated, this will
> force illumos-gate packages update (and BE creation) on a user system even
> if the user just wants to update, let's say, vim. And when you want just
> install security update for php on a server it's a problem if doing so
> requires reboot (for BE activation).
> I see several oppotunities.

> a) We say, that /hipster is a developer's OI version and it's enough if it
> just will not allow user to update package to non-functioning state (i.e.
> updating php 5.21 to 5.22 is not possible in the same BE if build server
> updated illumos-gate-produced packages between times when php 5.21 and 5.22
> versions were built). It's not a perfect scenario, but I'm OK with it. It's
> much better than allowing user to install php 5.22 in the same BE and to
> find out that  it is not functioning because of libc version bump.

> b) We update illumos-gate on the server once a (month/week/ ??? ) to allow
> some period of stability. Let's say, each Saturday, so for more important
> servers I can schedule update if necessary for Sunday.

> c) We update it by hand on "as strictly necessary" basis (perhaps, combining
> with once a month/quarter).
> Related question...

> If I have system/library version A installed on build machine and version
> A+N available in server's default repository, will dependent packages depend
> on version A or on A+N? Can we publish new illumos-gate versions, but hold
> build server's version?

I like option c), it will only work after using some new versioning
scheme though. Currently, incorporation versions are the same between
different illumos-gate builds and we would want to "pkg freeze"
specific version of illumos-gate incorporation on the build server.

> 4) The same question about IPS. As I understand, on each IPS update pkg will
> require new BE (and IIRC it refuses to install any new package until pkg is
> updated).
> I expect that pkg5 repository will not change as often as illumos-gate (at
> least after some time of initial bug-fixing). However, we should have some
> consistent update policy for it.

Perhaps we could tinker with pkg5 logic. I don't think new BEs are
really required when updating pkg5. It creates backup BEs anyway.

> 5) Just a question of taste. Don't you think that
> "4.2.45,5.11-0.2014.0.0.0.2476" is too long? I know, 5.11 is a sacred number
> in Solaris world, but I don't understand why should we have this magic in
> version string (for successful migration? Or IPS just will not like anything
> else?) and not very sure about 0 before year number. (Why not just
> 4.2.45-2014.0.0.0.2476  or MAGIC-2014.0.0.0.2476 for system packages?).
> I'm just whining and don't have strong opinion on this point :)

I don't mind the length of the version myself. The only part I am not
sure about is oi-userland git commit number at the very end. Maybe we
should store it as an attribute in the manifest itself not in the
version string, for example:

set name=info.oi-userland.commit-id
value=701319a26127991b79cd8b2e7e617e7f03b98fbd
set name=info.oi-userland.commit-url
value=https://github.com/OpenIndiana/oi-userland/commit/701319a26127991b79cd8b2e7e617e7f03b98fbd

0. in front of the year I left just in case we decide we want to have
version 1.0, 2.0, 3.0 in the future. Perhaps I was looking too far
into the future. We can drop it for now.

,5.11 bit is internal to pkg5 so can be ignored. You don't normally
see it but it is there in the package manifest pkg.fmri.

Cheers,

Andrzej