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 <[email protected]> wrote: > On 9 January 2014 23:06, Alexander Pyhalov <[email protected]> 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 [email protected] http://openindiana.org/mailman/listinfo/oi-dev
