https://bugzilla.redhat.com/show_bug.cgi?id=1816301 --- Comment #7 from mark.olesen@xxxxxxxxxxxxx --- (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. > 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". > 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? > %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. > Buildroot should not be set: > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_tags_and_sections 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 _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx
