I'm not entirely following you. Your examples in your README.rst —
lua-devel and nasm — are available in RHEL9 and CentOS Stream 9. They are
in the CodeReady Builder repos.
I sampled a few of the packages in
too. libev is in
the base. libuv-devel is in CodeReady Builder. Ditto for gtest-devel and
libunwind-devel.
At least I can install them using dnf on my vanilla employee SKU RHEL9 and
CentOS Stream 9 boxes.
If these packages are already in RHEL — in base, CodeReady Builder, or
AppStream — they won't be added to EPEL. It's not allowed.
For the rest of the packages that are in that list and/or in the trello
board which are not already in RHEL, I'd start by asking that they be added
to CodeReady Builder (or AppStream.) Then, if RHEL engineering won't add
them, the next step is to ask for them in EPEL. Or you could go about it
backwards, and add them to EPEL until they're added to CodeReady Builder.
On Mon, Mar 27, 2023 at 4:17 PM Ken Dreyer <kdreyer(a)redhat.com> wrote:
Yeah, unfortunately we had all of these in the Copr,
and some
infrastructure change deleted them:
https://bugzilla.redhat.com/show_bug.cgi?id=2143742
So the quickest route back will be to rebuild the missing-from-EPEL
packages with the newer Copr settings, and I have written notes for
that in
https://github.com/ktdreyer/ceph-el9
And the longer-term solution is to get the packages into EPEL proper.
- Ken
On Mon, Mar 27, 2023 at 4:04 PM Casey Bodley <cbodley(a)redhat.com> wrote:
i would hope that packaging for epel9 would be relatively easy, given
that the epel8 packages already exist. as a first step, we'd need to
build a full list of the missing packages. the tracker issue only
complains about python3-asyncssh python3-pecan and python3-routes, but
some of their dependencies may be missing too
On Mon, Mar 27, 2023 at 3:06 PM Ken Dreyer <kdreyer(a)redhat.com> wrote:
>
> I hope we don't backport such a big change to Quincy. That will have a
> large impact on how we build in restricted environments with no
> internet access.
>
> We could get the missing packages into EPEL.
>
> - Ken
>
> On Fri, Mar 24, 2023 at 7:32 AM Ernesto Puerta <epuertat(a)redhat.com>
wrote:
> >
> > Hi Casey,
> >
> > The original idea was to leave this to Reef alone, but given that
the
CentOS 9 Quincy release is also blocked by missing Python packages, I
think that it'd make sense to backport it.
> >
> > I'm coordinating with Pere (in CC) to expedite this. We may need
help to troubleshoot Shaman/rpmbuild issues. Who would be the best one to
help with that?
> >
> > Regarding your last question, I don't know who's the maintainer of
those packages in EPEL. There's this BZ (
https://bugzilla.redhat.com/2166620) requesting that specific package,
but that's only one out of the dozen of missing packages (plus transitive
dependencies)...
> >
> > Kind Regards,
> > Ernesto
> >
> >
> > On Thu, Mar 23, 2023 at 2:19 PM Casey Bodley <cbodley(a)redhat.com>
wrote:
> >>
> >> hi Ernesto and lists,
> >>
> >> > [1]
https://github.com/ceph/ceph/pull/47501
> >>
> >> are we planning to backport this to quincy so we can support centos
9
> >> there? enabling that upgrade path
on centos 9 was one of the
> >> conditions for dropping centos 8 support in reef, which i'm still
keen
> >> to do
> >>
> >> if not, can we find another resolution to
> >>
https://tracker.ceph.com/issues/58832? as i understand it, all of
> >> those python packages exist in centos 8. do we know why they were
> >> dropped for centos 9? have we looked into making those available in
> >> epel? (cc Ken and Kaleb)
> >>
> >> On Fri, Sep 2, 2022 at 12:01 PM Ernesto Puerta <epuertat(a)redhat.com>
wrote:
> >> >
> >> > Hi Kevin,
> >> >
> >> >>
> >> >> Isn't this one of the reasons containers were pushed, so that
the packaging isn't as big a deal?
> >> >
> >> >
> >> > Yes, but the Ceph community has a strong commitment to provide
distro packages for those users who are not interested in moving to
containers.
> >> >
> >> >> Is it the continued push to support lots of distros without
using containers that is the problem?
> >> >
> >> >
> >> > If not a problem, it definitely makes it more challenging.
Compiled components often sort this out by statically linking deps whose
packages are not widely available in distros. The approach we're proposing
here would be the closest equivalent to static linking for interpreted code
(bundling).
> >
> > Thanks for sharing your questions!
> >
> > Kind regards,
> > Ernesto
> > _______________________________________________
> > Dev mailing list -- dev(a)ceph.io
> > To unsubscribe send an email to dev-leave(a)ceph.io
>