#247 RFE: provide a way to pass a custom repository
Closed: Invalid None Opened 9 years ago by rholy.

The switch called "--local-repo" is a nice improvement in dealing with a problem of reviewing packages that depend on some not yet released packages. However it means that you have to resolve the dependencies needed to be installed a the mock chroot in advance and copy just the necessary RPMS into the "--local-repo" directory.

It would be nice if "--local-repo" switch would work rather the same as a "--local-repo" switch of "mockchain". I mean it would add a real repository into the mock root so that the underlying package manager would install the missing dependencies if necessary. Actually, since fedora-review already uses mock, you can probably easily implement such a behaviour.

I don't insist on changing changing the behaviour of the current "--local-repo" switch. Another switch would work for me too. Although, if you change the behaviour, you would be consistent with the underlying mockchain.


Adding a repository to a mock build is basically a mock thing. If you can't achieve what you want using the fedora-review --mock-options/-o option I cannot really understand how fedora-review could support this.

I'm inclined to close this as not-a-buǵ unless there is more input.

Hm, the current behaviour of --local-repo also cannot be achieved by using "-o" options and you still have it. Anyway, I think that the drawback of --local-repo is clear from the RFE description. If you think that I would be the only user who would benefit from having the proposed behaviour, feel free to close it. But the reasoning above doesn't sound reasonable.

And... saying that fedora-review cannot support something because the underlying libraries doesn't support it is not acceptable. The libraries can be extended. Or fedora-review can implement the workaround that I would need to implement otherwise. The only acceptable justification is that I'm requesting something that shouldn't be supported by fedora-review for a good reason.

And I believe that fedora-review should support my use case: I have a package that requires some packages that were not released yet. I run fedora-review as part of an automated process. Before running fedora-review, the missing dependencies are build. But the process does not know which of these binary packages are needed and not all of them can be installed together (some of them conflict). So, the process now needs to call a tool which tells it what packages will be needed, select the appropriate RPM files and pass them to --local-repo. Moreover, this (the dependency resolution and search) is performed later again for the rest of the dependencies by fedora-review when building the package in mock.

Replying to [comment:3 rholy]:

And... saying that fedora-review cannot support something because the underlying libraries doesn't support it is not acceptable. The libraries can be extended. Or fedora-review can implement the workaround that I would need to implement otherwise. The only acceptable justification is that I'm requesting something that shouldn't be supported by fedora-review for a good reason.

This might just a language barrier issue or my broken english but, reading this I felt kinda attacked/aggressed.

mock supports having local rpm repos which allow building rpm using dependencies set-up in that local rpm repo. Yes fedora-review could copy the mock config, tweak it, create the local repo (calling createrepo and all), handle failures, permission errors... but this will also add quite a layer of complexity on its code base and introduce a higher maintenance burden.

If you feel so strongly about this issue, have you thought about submitting a patch? And volunteer to maintain it?

Finally, you are right that libraries can be extended, difficulties can be worked around, but at the end it's the person doing the work that gets to decide on what he/she wants to work and what to prioritize.
Things can be discussed and opinions can be changed, but that might imply a little more than "I believe that fedora-review should support my use case", maybe some explanation of what you do, in which context, how reproducible the set-up is, how many people can benefit from it.

But then again, I might have mis-understand the message you were trying to convey.

Yes, it must be a language barrier. My English is far from being perfect. I just wanted to explain why I don't agree with closing this as "NOTABUG". Especially since this is an RFE. But sure, I admit that it's your issue tracking system and it's up to you how you use it. So, please, don't take it personally. Actually, I'd appreciate if you could explain (either here or privately) what made you feel attacked so that I can avoid repeating the mistake in the future.

If it is about not having enough resources to implement this, I'd personally choose "WONTFIX" or just leave it open for possible volunteers. To your question, yes, I may take a look. Not in the near future but at some time yes. But if a report is closed, personally, I take it as being rejected and thus not being worth taking a look.

And ad the requested explanation: I wanted to run fedora-review as part of our continuous integration process to prevent introduction of some packaging problems. For the beginning, the output of the review is not going to be further processed. It would be just available for later inspection. The package that is being tested depends on another (sub)package that is also build as part of the process.

The simplest reproducer I can think of is:
{{{
sudo cat << 'EOF' > pkg.spec
Name: pkg
Version: 1
Release: 2
Summary: the tested package
License: MIT
BuildArch: noarch
BuildRequires: dep-b == 1-2
%description
the tested package

%files
EOF

rpmbuild -bs pkg.spec

sudo cat << 'EOF' > dep.spec
Name: dep
Version: 1
Release: 2
Summary: the dependency
License: MIT
BuildArch: noarch
%description
the dependency

%package a
Summary: the dependency - variant A
Conflicts: %{name}-b
%description a
the dependency - variant A

%package b
Summary: the dependency - variant B
Conflicts: %{name}-a
%description b
the dependency - variant B

%files
%files a
%files b
EOF

rpmbuild -bb dep.spec
mkdir repo
cp ~/rpmbuild/RPMS/noarch/dep--.noarch.rpm repo

Actually, this may be done automatically if the current UX should be preserved.

createrepo repo

fedora-review --rpm-spec --name ~/rpmbuild/SRPMS/pkg--.src.rpm --mock-config fedora-rawhide-x86_64 --some-switch repo
}}}

IIUIC, the switch --local-repo DIR is useful for people who review packages that have some unavailable dependencies. In that case, I think that every such person should benefit from not having to parse (and resolve) which dependencies they should copy into the DIR. But I can only guess. Feel free to lower the priority.

I can be wrong in understanding what exactly is needed here but when I see there is a dependency chain of packages I need to review, I start with leaf package(s), review it, copy its built rpms into some location on my system and create a repo from it and add it as baseurl to [local] section of /etc/mock/fedora-rawhide-x86_64.cfg file. I will then keep adding such all packages and keep doing reviews till the final package in dependency chain gets reviewed.

I never tried to find how to pass different local repository locations to fedora-review command.

Replying to [comment:6 pnemade]:

I can be wrong in understanding what exactly is needed here but when I see there is a dependency chain of packages I need to review, I start with leaf package(s), review it, copy its built rpms into some location on my system...

What you can instead is:

  • Build the dependencies
  • Create a local directory and copy the the dependencies to it
  • Use the --local-repo option with your directory as argument.

This should actually save you some work, and leave a pristine etc/mock/fedora-rawhide-x86_64.cfg in place.

Replying to [comment:5 rholy]:

If it is about not having enough resources to implement this, I'd personally choose "WONTFIX" or just leave it open for possible volunteers. To your question, yes, I may take a look. Not in the near future but at some time yes. But if a report is closed, personally, I take it as being rejected and thus not being worth taking a look.

Fair enough, WONTFIX is a better resolution. I will close this bug, but that is not to say it's a bad idea, it's just about keeping the list of open bugs manageable. Thanks for bringing this up, and please reopen bug if/when you have a patch or similar input available.

Replying to [comment:3 rholy]:

And I believe that fedora-review should support my use case: I have a package that requires some packages that were not released yet. I run fedora-review as part of an automated process. Before running fedora-review, the missing dependencies are build. But the process does not know which of these binary packages are needed and not all of them can be installed together (some of them conflict). So, the process now needs to call a tool which tells it what packages will be needed, select the appropriate RPM files and pass them to --local-repo. Moreover, this (the dependency resolution and search) is performed later again for the rest of the dependencies by fedora-review when building the package in mock.

Basically, as of now fedora-review has a lot of rough edges in these kind of usecases. E. g., we have tried to run f-r on all packages in the distribution, an obvious nice thing to do but it turned out to be really complicated. Basically, f-r probably needs a major redesign to support this kind of usage in an effective way.

FYI, I've filed an RFE against Mock for easier implementation of this, see https://bugzilla.redhat.com/show_bug.cgi?id=1221928.

Login to comment on this ticket.

Metadata