proper structuring of a package
I've been in discussion with Kurt about the openfoam package and have
been looking at adjusting (improving) its structure.
Being very new to debian (and especially debian packaging), there are a
few things that I'd like to get some more ideas about - thus the posting
here.
With OpenFOAM it is fairly common for users to have multiple versions
installed at any one time. For example, to migrate coding for API
changes between versions, or to validate the results of models using
different versions before making a complete switch, or even if an
element is partly broken in a newer version but works in an older version.
In the RPM world, I've handled this by an admittedly somwehat ugly approach.
1) Version-specific packages such as openfoam1906, openfoam1912 etc with
a "minor" version according to the patch-level (eg,
https://build.opensuse.org/package/view_file/science/openfoam1912/openfoam1912.spec)
2) An openfoam meta-package to specify the latest production version by
requiring the version-specific package (eg,
https://build.opensuse.org/package/view_file/science/openfoam/openfoam.spec)
To allow simultaneous installation of multiple versions, I'm installing
into /opt/openfoam1912, /opt/openfoam1906 etc. This is okay for a
third-party package, but not for a debian-package. What would be the
correct place for these?
IMO, using alternatives is not viable. There are simply too many exes
and libs, names may change, etc.
Had thought about dropping everything into a multi-arch directory, but
not sure how that should be properly realised, and where the sources
would then be located.
Looking for ideas and discussion.
Cheers,
/mark
Reply to: