Learn more about these different git repos.
Other Git URLs
kojira supports --with-src option and I think we don't use it now.. So now I have to download 60G of SRPMs just to generate source repo locally =(
--with-src
That would be awesome if you will set up kojira to generate source rpms repo along with normal ones, so we will be able to consume it without needing to download thousands of SRPM.
P.S. I'm not sure whether this request is for releng or infra..
Can you please explain the problem you are trying to solve and how it is not solved by the existing source repos for branched, rawhide and stable releases?
-build
you can not guarantee that the BuildRequires are correct using any repo. There is such a thing as architecture specific BuildRequires that are only visible by rebuilding the srpm for each specific arch. glibc32 should not be a consideration really. it is a hack in order to be able to build a gcc that supports building both 32 and 64 bit binaries. it is something that should only exist today on x86_64 it is created by taking bits from glibc and glibc-devel rpms from i686 and shoving them in a x86_64 rpm. using mock locally you would get the same result from having glibc-devel.i686 and glibc.i686 installed there is a requirement that packages using this must BR /lib/libc.so.6 for instance
can not guarantee that the BuildRequires are correct using any repo
we manually crafted list of packages which are changing its BuildRequires on different architectures
There is such a thing as architecture specific BuildRequires that are only visible by rebuilding the srpm for each specific arch
That's why we filled https://pagure.io/releng/issue/6819
using mock locally you would get the same result from having glibc-devel.i686 and glibc.i686 installed there is a requirement that packages using this must BR /lib/libc.so.6 for instance
We would prefer not to deal with handling multilib locally...
you can extend your hack for glibc32. There is no need to deal with multilib locally as its in the fedora repos. and gets handled automatically
gcc.spec has %ifarch %{multilib_64_archs} sparcv9 ppc
BuildRequires: /lib/libc.so.6 /usr/lib/libc.so /lib64/libc.so.6 /usr/lib64/libc.so %endif
in order to pull the bits in, the repos as shipped provide the correct bits, you just need to know that in koji it is glibc32 and outside is glibc-devel.
In order to even contemplate making changes that would make the metadata accurate we would need changes in koji, pungi and all our tools and pipeline. as well as budget for extra disk as we would need significantly more disk. or potentially we get some new microservice that parses the spec on changes, and records the data in a queriable database. requireing less disk
@kevin , should this ticket move to your Infra queue? Please advise.
I think we don't want to do this. We have not wanted to any in the past... It adds disk storage and cpu requirements for almost no benefits.
So, IMHO we should just close this.
But if @ignatenkobrain still wants this and would like to try and convince us again, he should do so. ;)
Closing this ticket as per @kevin . Please reopen if still requested.
Metadata Update from @syeghiay: - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.