[oi-dev] OpenIndiana /hipster build number

Thu Jan 16 08:03:27 UTC 2014

Hi All

I was wondering if other people had any concerns or questions about
the proposed versioning scheme?

Cheers,

Andrzej

On 13 January 2014 09:34, Andrzej Szeszo <aszeszo at gmail.com> wrote:
> 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