#6827 RFE: kojira to create src repos
Closed 5 years ago Opened 6 years ago by ignatenkobrain.

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 =(

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?

  • Why to use -build repo directly? Because this is exactly what koji uses to build packages and composes are missing some packages from there (e.g. glibc32)
  • We use source repos to get BuildRequires of some particular package to find them recursively (aka which packages are needed in order to build bash systemd and dnf)
  • Another point for using -build repos is to detect dependency grow as soon as possible to prevent composes growing

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

Ensure glibc{,-devel} is installed for both multilib arches

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)

5 years ago

Login to comment on this ticket.

Metadata