[oi-dev] OpenIndiana /hipster build number

Thu Jan 16 18:49:05 UTC 2014

My biggest question is how and when do we move things from /hipster to a
testing repo (no non-bugfix changes) and from there to a release.

It would be nice if at the same time we made the "old" hipster repo the
"new" testing repo, give it a month, then duplicate it into stable.
(keeping the old one around for testing incase we catch any bugs later, but
before the new promotion)

Andrzej Szeszo <aszeszo at gmail.com> wrote on 01/16/2014 02:03:27:
>
> 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
>
> _______________________________________________
> oi-dev mailing list
> oi-dev at openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openindiana.org/pipermail/oi-dev/attachments/20140116/c01bb623/attachment.html>