is anyone aware what the best source is to fetch the upstream srpm packages?
i am currently only aware of this: ftp://ftp.redhat.com/pub/redhat/linux/enterprise/
is there also a public srpm yum repo, available via https?
otherwise i am only aware of https://cdn.redhat.com/, which requires a subscription to get access to.
On the FTP site I miss the Base and AppStream source packages. It looks like only the additional products they have are on there. So I don’t think this one is suitable. This means https://cdn.redhat.com is the one to use (as I also don’t know any other way).
Yes, this will be the one to use. @schlitzered we will pull directly from RHEL just as Oracle (and another EL like distro) do. You can sign up for a free dev subscription and access the cdn, no questions asked, to pull the repos with reposync.
The canonical sources for all CentOS/RHEL stuff is on the CentOS Pagure instance at https://git.centos.org. Everyone gets their sources from here, since that’s what Red Hat pushes to.
After a RHEL release, the RHEL sources are sent to https://git.centos.org so if you clone the repos (IIRC in rpms/ and modules/) then you have everything.
Why not grab the CentOS 8.3.2011 SRPMs from https://vault.centos.org (or the rsync mirrors)? That should give you a good start.
@Conan_Kudo @patrick The problem is MOST branches are 8 stream centric (look at an appstream module), so how do you differentiate what’s part of a point release (eg 8.3, 8.4) versus stream? Seems difficult, no? The sources should come from Red Hat, not the centos git because of the lack of being able to tell between what is stream and a given point release. Oracle and others do it, we’ll do the same thing.
i feel like, relying on CentOS infrastructure is not what we should do, we should directly mirror from RHEL
it seems like only the latest version of RHEL (8.3) is available using the developer subscription.
is there also a way to get older versions?
i mean, only having access to latest RHEL might be okay for now. since this projects tries to clone EL 8.
but what if RHEL 9 comes out, will we loose access to RHEL 8 sources?
Good point. If CentOS git does not differentiate then it’s of no use.
No, you never lose access to previous sources. You can still obtain the EL7 (and much older) sources on their FTP site or through a registered machine.
I wouldn’t expect to see older releases of 8.x unless you are using EUS or have been reposyncing since basically 8.0 GA. Producing an 8.0 imo is not the right approach. Starting from a current release (in our case, 8.3) would be the best bet. If we’re feeling particularly giving, we can also build an EL7, but CentOS 7 will still be around till 2024 (it’s in phase 2 of support).
Yes. I agree. We should focus only on current RHEL release, so RHEL8.3->Rocky8.3.
I mean, no Rocky7 (why the effort? seems Centos7 is there, at least for now…). No Rocky 8.1,8.2 (pointless, the first thing you would do anyhow is to do an upgrade to get latest package updates).
EL 7 still has a 3 year window bug for bug support
it seems like git.centos.org is indeed the official source for RHEL source code nowadays.
see https://wiki.centos.org/About/Building_7
quote: “Red Hat makes the sources available. This used to be done via src.rpms but 7 changed to git repos (at https://git.centos.org/)”
Pulling from git.centos.org you have no way of distinguishing of what’s a minor release. eg, what’s 8.3 vs stream when it comes to modules? There are efforts right now of people pulling down the sources from Red Hat using a devsub, free of charge. Eventually we’ll need a rockylinux sub account to pull the source RPM’s from instead of using a git forge that is mainly dedicated to stream at the branch levels.
As mentioned, a valid subscription (including Developer) gives you access to current and previous RHEL versions and associated source RPMs.
These packages can be pulled by locking subscription manager to a minor version and then downloading (or syncing) source RPMs for that version.
subscription-manager release --set=8.3
Yep, and if it helps for confirmation, here’s a list of the available kernel sources with my Developer Subscription:
$ sudo dnf list --showduplicate kernel.src --enablerepo=rhel-8-for-x86_64-baseos-source-rpms
Updating Subscription Management repositories.
Last metadata expiration check: 0:02:15 ago on Thu 10 Dec 2020 11:12:26 PM EST.
Available Packages
kernel.src 4.18.0-80.el8 rhel-8-for-x86_64-baseos-source-rpms
kernel.src 4.18.0-80.1.2.el8_0 rhel-8-for-x86_64-baseos-source-rpms
kernel.src 4.18.0-80.4.2.el8_0 rhel-8-for-x86_64-baseos-source-rpms
kernel.src 4.18.0-80.7.1.el8_0 rhel-8-for-x86_64-baseos-source-rpms
kernel.src 4.18.0-80.7.2.el8_0 rhel-8-for-x86_64-baseos-source-rpms
kernel.src 4.18.0-80.11.1.el8_0 rhel-8-for-x86_64-baseos-source-rpms
kernel.src 4.18.0-80.11.2.el8_0 rhel-8-for-x86_64-baseos-source-rpms
kernel.src 4.18.0-147.el8 rhel-8-for-x86_64-baseos-source-rpms
kernel.src 4.18.0-147.0.2.el8_1 rhel-8-for-x86_64-baseos-source-rpms
kernel.src 4.18.0-147.0.3.el8_1 rhel-8-for-x86_64-baseos-source-rpms
kernel.src 4.18.0-147.3.1.el8_1 rhel-8-for-x86_64-baseos-source-rpms
kernel.src 4.18.0-147.5.1.el8_1 rhel-8-for-x86_64-baseos-source-rpms
kernel.src 4.18.0-147.8.1.el8_1 rhel-8-for-x86_64-baseos-source-rpms
kernel.src 4.18.0-193.el8 rhel-8-for-x86_64-baseos-source-rpms
kernel.src 4.18.0-193.1.2.el8_2 rhel-8-for-x86_64-baseos-source-rpms
kernel.src 4.18.0-193.6.3.el8_2 rhel-8-for-x86_64-baseos-source-rpms
kernel.src 4.18.0-193.13.2.el8_2 rhel-8-for-x86_64-baseos-source-rpms
kernel.src 4.18.0-193.14.3.el8_2 rhel-8-for-x86_64-baseos-source-rpms
kernel.src 4.18.0-193.19.1.el8_2 rhel-8-for-x86_64-baseos-source-rpms
kernel.src 4.18.0-193.28.1.el8_2 rhel-8-for-x86_64-baseos-source-rpms
kernel.src 4.18.0-240.el8 rhel-8-for-x86_64-baseos-source-rpms
kernel.src 4.18.0-240.1.1.el8_3 rhel-8-for-x86_64-baseos-source-rpms
Just continuously reposyncing (and hopefully automating the ingest into git) of the source repos should be enough.
Given that RH has already pulled the rug out from under CentOS, I don’t think it would be wise to establish any of Rocky’s infrastructure with a reliability on any of the CentOS infrastructure. “Today”, RH is pushing code to git.centos.org, but will that change in the future? Will it become upstream as well? Rocky should make sure it is future proof on that front.
I expect that to be the case, similar to what CloudLinux does and other vendors, they build directly from RHEL sources. I agree with someone else that posted here another topic that instructions on how to build from sources should be open and very well documented.
Yes, this has been discussed several times over. We will be using red hat’s sources directly instead of relying on the centos git, we do not want to chance anything around the dec 2021 mark.
I’m not here to argue the merits of Red Hat’s decisions or justify the actions leading up to today. I do implore you to ensure you understand the TOS of anything you would clickthrough to receive access to sources via a Dev Sub. Rehosting sources downloaded from the Red Hat Portal would violate these terms.
We would prefer the community leverage the publicly available repos, for which I’m not here asking for your trust on. Believe it or not, we are absolutely encouraging downstream projects and want to see them thrive. What we don’t want, is lawyers in the way.