https://bugzilla.redhat.com/show_bug.cgi?id=1816301
--- Comment #8 from Ankur Sinha (FranciscoD) <sanjay.an...@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/#_conditionals 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_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@lists.fedoraproject.org To unsubscribe send an email to package-review-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
