archiving/relocating packages?
I am maintaining OpenFOAM (www.openfoam.com) packaging on the science repo and need some advice. For various reasons, we maintain the last few releases as packages, which are also designed to allow side-by-side installation with each other. Currently I have all of the versions in separate projects: - science/openfoam1912 - science/openfoam2006 - science/openfoam2012 and a meta-package to reference the current version: - science/openfoam (requires openfoam2012) This can be simplified by simply folding the meta-package and versioned-packages together. In doing so, the science/openfoam would sensibly contain the full build of the most recent stable version. But when a future version comes out, I would then like to "archive" the current state (eg, 2106) appropriately: 1. openfoam using 2106 2. "snapshot" of "openfoam" as "openfoam2106" project 3. update openfoam to 2112 and rebuild/republish Is there any way to do this apart from a manual copy and update, which would presumably also trigger a complete rebuild of the existing packages? Or is there a better approach to this? Thanks, /mark
Hey Mark, On 4/21/21 10:42 AM, Mark Olesen wrote:
I would then like to "archive" the current state (eg, 2106) appropriately:
What do you want to achieve with the "archive" step? You create a science: -- Henne Vogelsang http://www.opensuse.org Everybody has a plan, until they get hit. - Mike Tyson
Hi Henne, The idea of the "archiving" is that when a new OpenFOAM version appears (6-month release cycle), it is fairly common for end users to require a back-to-back comparison of two or more versions before migrating to a new version as a production standard. They might want to verify that the lift/drag or separation point doesn't change by more than a certain amount, or that mesh coverage has improved etc. So ideally we try to keep the last 3 major versions maintained and available as RPMs to allow a fixed reference point of binaries for comparison. It would be relatively simple to generate a new package and copy across the old tar, spec, changes to it, but this would necessarily trigger a new rebuild for something that already exists. I hope that explains what I'm aiming for. Cheers, /mark On 4/21/21 7:19 PM, Henne Vogelsang wrote:
Hey Mark,
On 4/21/21 10:42 AM, Mark Olesen wrote:
I would then like to "archive" the current state (eg, 2106) appropriately:
What do you want to achieve with the "archive" step?
You create a science:
Helo Mark, Am Mittwoch, 21. April 2021, 22:00:35 CEST schrieb Mark Olesen:
The idea of the "archiving" is that when a new OpenFOAM version appears (6-month release cycle), it is fairly common for end users to require a back-to-back comparison of two or more versions before migrating to a new version as a production standard. They might want to verify that the lift/drag or separation point doesn't change by more than a certain amount, or that mesh coverage has improved etc.
Not sure if it matches your case exactly, but I have a similar situation wth GNU Health and Tryton: New versions of this ERP come every ~12 month. User usually stay a bit longer with one version, so it makes sense to maintain older versions as well. So there is Application:ERP:GNUHealth:3.4 Application:ERP:GNUHealth:3.6 Application:ERP:GNUHealth:3.8 and always the latest version points to Application:ERP:GNUHealth:Factory from where Factory is fed. It is quite important that packages from each of the repos are not mixed up, so keeping them separate is crucial HTH Axel
Hi Axel, This looks quite close, which means that would need to restructure with different sub-projects. The only annoying part is that you need to enable additional zypper repos for each subproject. May that is actually a feature - hard to say. Will need to see how all the project linking works too. Thanks to the information (also happy to receive any more that you might have). LG, /mark
Not sure if it matches your case exactly, but I have a similar situation wth GNU Health and Tryton: New versions of this ERP come every ~12 month. User usually stay a bit longer with one version, so it makes sense to maintain older versions as well. So there is Application:ERP:GNUHealth:3.4 Application:ERP:GNUHealth:3.6 Application:ERP:GNUHealth:3.8 and always the latest version points to Application:ERP:GNUHealth:Factory from where Factory is fed. It is quite important that packages from each of the repos are not mixed up, so keeping them separate is crucial
HTH Axel
Hey, On 21.04.21 22:00, Mark Olesen wrote:
this would necessarily trigger a new rebuild for something that already exists.
And you want to avoid this because? :-) Henne -- Henne Vogelsang http://www.opensuse.org Everybody has a plan, until they get hit. - Mike Tyson
this would necessarily trigger a new rebuild for something that already exists.
And you want to avoid this because? :-)
Apart from the resources question (CO2 etc), it looks like it could create a strange release numbering. Assuming we start off like this: Project "openfoam" with that generates - openfoam-<version>-<release> (meta package) - openfoam<api>-<version>-<release> (payload package) With some concrete values: - openfoam-2012.210414-lp152.4.3 <rpm> - openfoam2012-2012.210414-lp152.4.3 <rpm> To "archive" them, I would presumably spinoff my archive project as "openfoam2012" and copy/rename the spec file. Since this would be a new project, it will presumably have its own internal release numbering. Eg, would now create these: - openfoam-2012.210414-lp152.1.1 <<-- new accounting - openfoam2012-2012.210414-lp152.1.1 <<-- new accounting Not sure I would have to wait for these to be generated and published before moving on, but I could then proceed to edit the "openfoam" project to bump to a new major version etc. However, I make any minor build/spec tweaks to the "openfoam2012" archived project, it could take a while until it finally overtakes the older release version. Could be confusing to say the least. Or am I misunderstanding something fundamental about how the build system works? Cheers, /mark
Hey, On 23.04.21 17:06, Mark Olesen wrote:
this would necessarily trigger a new rebuild for something that already exists.
And you want to avoid this because? :-)
Apart from the resources question (CO2 etc)
Well you are "renaming" the package container and changing the build description. Both have possible influence on the build process and also your repository. It sounds to me you *need* to rebuild. It also sounds to me you are trying to solve the problem (a user want's to keep an old version installed) inside the repository that is best solved where it happens, on the users system. Henne -- Henne Vogelsang http://www.opensuse.org Everybody has a plan, until they get hit. - Mike Tyson
Hey, On 4/21/21 10:42 AM, Mark Olesen wrote:
I would then like to "archive" the current state (eg, 2106) appropriately:
What do you want to achieve with the "archive" step? Henne -- Henne Vogelsang http://www.opensuse.org Everybody has a plan, until they get hit. - Mike Tyson
On Mittwoch, 21. April 2021, 10:42:48 CEST Mark Olesen wrote:
I am maintaining OpenFOAM (www.openfoam.com) packaging on the science repo and need some advice.
For various reasons, we maintain the last few releases as packages, which are also designed to allow side-by-side installation with each other.
Currently I have all of the versions in separate projects: - science/openfoam1912 - science/openfoam2006 - science/openfoam2012
and a meta-package to reference the current version: - science/openfoam (requires openfoam2012)
This can be simplified by simply folding the meta-package and versioned-packages together.
In doing so, the science/openfoam would sensibly contain the full build of the most recent stable version. But when a future version comes out, I would then like to "archive" the current state (eg, 2106) appropriately:
1. openfoam using 2106 2. "snapshot" of "openfoam" as "openfoam2106" project 3. update openfoam to 2112 and rebuild/republish
Is there any way to do this apart from a manual copy and update, which would presumably also trigger a complete rebuild of the existing packages?
I think you can achieve this when you lock the packages in your project.
just add
<lock><enable/></lock>
to your package meta.
Does this help you?
--
Adrian Schroeter
I think you can achieve this when you lock the packages in your project.
just add
<lock><enable/></lock>
to your package meta.
Does this help you?
Probably doesn't help that much, but good to remember. The simplest seems to be create/rename when a new major version is added. Cheers, /mark
participants (4)
-
Adrian Schröter -
Axel Braun -
Henne Vogelsang -
Mark Olesen