On Wed, Feb 14, 2018 at 11:16 AM, Pavel Raiskup <praiskup(a)redhat.com> wrote:
On Wednesday, February 14, 2018 10:54:48 AM CET Michal Novotny
wrote:
> Hello Pavel,
>
> On Wed, Feb 14, 2018 at 10:18 AM, Pavel Raiskup <praiskup(a)redhat.com>
wrote:
>
> > On Tuesday, February 13, 2018 10:15:42 PM CET Michal Novotny wrote:
> > > On Tue, Feb 13, 2018 at 9:51 PM, Michal Novotny <clime(a)redhat.com>
> > wrote:
> > >
> > > > Hello,
> > > >
> > > > On Tue, Feb 13, 2018 at 12:54 PM, Michael Šimáček <
msimacek(a)redhat.com
> > >
> > > > wrote:
> > > >
> > > >> On 2018-02-13 11:47, Pavel Raiskup wrote:
> > > >>
> > > >>> Sorry, I wanted to CC fedora devel before, forwarding.
> > > >>>
> > > >>> Pavel
> > > >>>
> > > >>> On Tuesday, February 13, 2018 10:54:55 AM CET Pavel Raiskup
wrote:
> > > >>>
> > > >>>> Because we are unable to find a consensus on
implementation
details,
> > > >>>> it's
> > > >>>> likely we'll drop this feature from copr API and it
will be
> > probably a
> > > >>>> bit
> > > >>>> more complicated to setup mock chroot for local tests in
future
> > (you'll
> > > >>>> need to have builder machine with copr-rpmbuild
installed, which
> > brings
> > > >>>> a
> > > >>>> lot more runtime dependencies at least).
> > > >>>>
> > > >>>> From user perspective, do you mind if we dropped `copr
mock-config`
> > > >>>> command?
> > > >>>>
> > > >>>>
> > > >> I didn't know this command existed, but there were multiple
times
in
> > the
> > > >> past where I wished something like this had been available (It
didn't
> > exist
> > > >> back then). It was usually situation like this: "Hi, I'm
trying to
> > build
> > > >> $package in $copr and it fails because of $build_tool that you
> > maintain,
> > > >> can you help me?". And since I had no idea how his copr was
set
up,
> > it took
> > > >> me a lot of time before I was able to reproduce the problem. So,
I
> > would
> > > >> find the feature useful, especially in instances outside Fedora,
which
> > > >> usually have more complex configurations.
> > > >> If it had to be dropped, I'd appreciate if copr could display
the
> > > >> configuration of given project for non-owners. That way it would
be
> > easier
> > > >> to construct my own config, without trying to guess stuff based
on
> > the logs.
> > > >>
> > > >
> > > > First, thanks for your input. This is very useful information for
us.
> > > > Next, I would like to ask if it was ok to put all the functionality
> > about
> > > > build-testing and building itself into just a single package:
> > > > copr-rpmbuild. I think having things on just one place can help us
> > focus on
> > > > doing them really well and as the copr-rpmbuild tool is already
> > responsible
> > > > for building, I think it would be a perfect place to add additional
> > > > build-debugging functionality like printing-out/dumping mock
configs,
> > > > enablement to run just a part of the build process, possibility to
> > enter
> > > > the build environment interactively etc. Would this be alright?
> > > >
> > >
> > > I need to add that with this tool you really need to know _what_ you
are
> > > building to be on the safe side. It is similar to running rpmbuild
> > locally
> > > (unless you are really just dumping mock configs).
> >
> > I use 'copr mock-config' for working with buildroot, even if I
don't
want
> > to build anything (mock --shell). So except from mock, any other deps
> > installed by copr-rpmbuild are useless and I don't want them on my box
> > basically.
> >
>
> Alright, we can set some most prominent deps of copr-rpmbuild as weak
deps.
>
> It will be then possible to install the minimal package setup e.g. with:
>
> # dnf -y install copr-rpmbuild --setopt=install_weak_deps=False
>
> I opened
https://pagure.io/copr/copr/issue/222.
>
> Thanks!
I wouldn't be able to install copr-rpmbuild on EPEL7 then, where I still
can
install mock/copr-cli and I can experiment with copr bulidroot through
`copr
mock-config` feature. IOW, enforcing user to install another client tool
for generating mock config doesn't make sense.
Actually, I would like to make some deps as very weak deps ('Suggests' tag),
so that they are not installed by default.
I am not sure what's the status of yum in EPEL7 but I think it would be very
nice if this functionality was backported there. If not, I will need to add
separate
Require tags for rhel. But thanks for that note!