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(a)musicinmybrain.net
> <mailto:code@musicinmybrain.net>>
> Date: Mon, Feb 21, 2022, 22:11
> Subject: Re: Self Introduction: Yunmei Li
> To: <devel(a)lists.fedoraproject.org
<mailto:devel@lists.fedoraproject.org>>
>
> 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
>