Re: Self Introduction: Yunmei Li

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux