On 2/23/22 6:42 AM, Yunmei LI wrote:
Hi,
Thanks for your help! I reworked the Milvus package for EPEL8 based on
the comments I received, and updated theSpec URL and SRPMURL on
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2055596
<https://bugzilla.redhat.com/show_bug.cgi?id=2055596>
I am really lookingforward to someone reviewingMilvus package at the
earliest convenience.
Not a review, but does it build on Copr[1] or Koji[2] ?
It may be helpful to check the Go SIG recommendations[3],[4].
You may also find OpenBuildService helpful[5].
[1] https://copr.fedorainfracloud.org/
[2] https://koji.fedoraproject.org/koji/
[3] https://fedoraproject.org/wiki/SIGs/Go
[4] https://fedoraproject.org/wiki/PackagingDrafts/Go
[5] https://openbuildservice.org/
Thanks,
Yunmei Li
From: "Ben Beasley"<code@xxxxxxxxxxxxxxxxxx
<mailto:code@xxxxxxxxxxxxxxxxxx>>
Date: Mon, Feb 21, 2022, 22:11
Subject: Re: Self Introduction: Yunmei Li
To: <devel@xxxxxxxxxxxxxxxxxxxxxxx <mailto:devel@xxxxxxxxxxxxxxxxxxxxxxx>>
All current versions of *Fedora* have CMake 3.20 or later, so you
shouldn’t have any problems there.
When packaging for EPEL, you rely on the package versions that were
released with the corresponding version of Red Hat Enterprise Linux.
RHEL aims to provide long-term stability, so these mostly get bugfix
releases and security backports rather than significant updates over the
life of the distribution. This is largely the same update philosophy as
individual Fedora releases, but with a lifecycle on the order of a
decade rather than a year. Since RHEL 7.0 was released in 2014, most of
the packages you can use when building for EPEL7 are based on pretty old
upstream versions.
In most cases, if the dependency versions in a particular release of
RHEL don’t meet your needs, it means that it is not practical to build
your package for the corresponding version of EPEL. There are a few
exceptions—for example, you can get a newer compiler toolchain by using
one of the devtoolset releases, e.g. [1].
If you can package for EPEL7 successfully, but only by doing things that
don’t meet Fedora/EPEL guidelines (bundling dependencies without
satisfying the conditions in [2], packaging your own
newer-but-not-parallel-installable version of cmake to build with), then
you might still be able to offer a package for EL7 distributions via
COPR[3].
You might find that EPEL8 or EPEL9 are still viable targets. You also
might find that the epel-devel mailing list is a helpful place to ask
questions.
– Ben
[1] https://src.fedoraproject.org/rpms/sleef/blob/epel7/f/sleef.spec
[2] https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling
[3] https://docs.pagure.org/copr.copr/user_documentation.html#faq
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
