https://bugzilla.redhat.com/show_bug.cgi?id=1816301
--- Comment #8 from Ankur Sinha (FranciscoD) <sanjay.ankur(a)gmail.com> ---
(In reply to mark.olesen from comment #7)
(In reply to david08741 from comment #3)
Nice to get the reviews - it shows that people care!
> Not a full review, but some comments:
>
> Group: is deprecated, please remove
OK for RedHat, probably leave for SuSE.
If you intend to use the same spec, you'll have to resort to using
conditionals:
http://ftp.rpm.org/max-rpm/s1-rpm-specref-conditionals.html
The Fedora conditionals are listed here:
https://docs.fedoraproject.org/en-US/packaging-guidelines/DistTag/#_condi...
I do not know what the conditionals for SuSE are, so you'll have to refer to
their documentation.
> License should be: GPLv3+
>
https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#SoftwareLicenses
Interesting, any idea why are they not using or accepting
https://spdx.org/licenses/?
Thought this would be "standard".
The Red Hat/Fedora legal team oversees the licensing, so we stick to what they
suggest :)
> Name should probably not include the version:
> Name: openfoam
>
> I am not sure whether this is a MUST, but the release should start at 1 and
> be bumped whenever you change the spec, without a new release:
These are both open to discussion and suggestion about how best to solve.
OpenFOAM releases on a 6-month cycle in Jun and Dec, with version (API)
denoted as YYMM (eg, 1906, 1912).
Since the API and the internal models most certainly change between these
releases, it is fairly standard practice to have multiple versions installed
or installable on the system. There are various reasons that this is
desirable:
- allows testing, porting of user models to the updated framework
- allows back-to-back comparison of simulation results, validation cases etc.
- avoids automatic upgrades of major versions. For some industries it is
normal to continue with a particular major version for the development
lifetime of a product (eg, a vehicle).
The best way that I came up with was to have numbered packages (eg,
openfoam1912, openfoam1906, etc) and use a top-level "openfoam" meta-package
to define what is the most current release. I guess it could be comparable
to having Qt4, Qt5, kde4, kde5, etc, except that the release numbers update
every 6 months.
On copr, I'm just now experimenting with using the bugfix (patch) value for
the version. The patch value follows a YYMMDD value. This means that the
current spec would then have
Name: openfoam1912
Version: 200316 # <- 2020-03-16
The release could than have the usual increment I guess?
This is OK. No problem here as long as the various openfoam packages don't
conflict with each other.
> %defattr(-,root,root,-) isn't needed, please remove
OK
> I don't think prefix should be set; it is certainly not allowed to use /opt
This was also something that was discussed off-line (Fedora and Debian).
Need to have isolated, version-specific directories, but using an
"alternatives" framework does not appear to be a good fit.
We have approximately 300 executables and 160 libraries to deal with. I
can't imagine fitting them all into alternatives. Besides which, the choice
of which OpenFOAM version to use should be a user choice, not a systems
choice.
Did look at trying to drop everything into /usr/lib/, or even install as
multi-arch, but without proper guidance decided on /opt for the moment.
I am most certainly open to suggestions.
As noted, /opt certainly cannot be used. The best solution here depends on the
software. If it's only the binaries we need to worry about, they can simply be
suffixed with the version. This also clearly tells the user what version they
are using. This is how mpi variants for packages are built, for example.
Libraries are much trickier, especially if they use the same names between
variants. Are the soname versions different at least? Otherwise even using /opt
will only work if the LD_LIBRARY_PATH is updated each time to give the correct
version preference, right?
> Buildroot should not be set:
>
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_tags_and_sect...
OK, might have been working from some older docs.
> '%package -n %{name}-examples' -> '%package examples'
Nice, much cleaner.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component