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:

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

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 <adrian@suse.de> Build Infrastructure Project Manager SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany (HRB 247165, AG München), Geschäftsführer: Felix Imendörffer

...

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