Bug 1023908 - RFE: support for user configuration
Summary: RFE: support for user configuration
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: mock
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Clark Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-10-28 10:08 UTC by Marcin Juszkiewicz
Modified: 2014-07-28 14:54 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-07-28 14:54:03 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Marcin Juszkiewicz 2013-10-28 10:08:19 UTC
Description of problem:

I do lot of builds with mock. Each time I have to give "--resultdir=~/rpmbuild/mock/PACKAGENAME-PACKAGEVER -v" or do it in shell script. Would be great if all mock options could be set in some user configuration file.

Users building for custom distributions could use own distro configs without asking system administrator for copying their configs into /etc/mock directory.

Actual results:

All options have to be given on each invocation of mock.

Expected results:

"mock path/to/package.src.rpm" builds according to user specification.

Additional info:

I came from Debian and used pbuilder a lot.

Comment 1 Mathieu Bridon 2013-10-28 10:39:59 UTC
That would be nice indeed.

If I may suggest, please use ~/.config/mock/ rather than ~/.mock/

Mock is clearly not a desktop application, but it would still be nice to follow the FreeDesktop.org spec here, to avoid polluting people's HOME dire with more of .files, and make it easier to backup user configuration. :)

There's the pyxdg module in Python to get the right folder to use:

>>> from xdg.BaseDirectory import xdg_config_home
>>> xdg_config_home
'/home/mathieu/.config'

Comment 2 Mathieu Bridon 2013-10-28 10:40:51 UTC
Forgot to mention: I'd be willing to work on a patch if that's a desired change. :)

Comment 3 Clark Williams 2013-10-28 17:53:51 UTC
I'd be happy to accept a patch from you Mathieu :)

You may want to wait for 1.1.34 before doing any serious work. I'm testing it now and once it gets past basic checks I'll create an update for it and will update my git tree.

Comment 4 Mathieu Bridon 2013-11-04 06:14:06 UTC
Huh, this seems to already exist, actually:

    $ cat ~/.mock/user.cfg
    config_opts['root'] = 'fedora-rawhide-x86_64-modified-from-user-config'
    config_opts['resultdir'] = "/var/lib/mock/myresultdir"

    $ mock -r fedora-rawhide-x86_64 --rebuild ipset-6.20.1-1.fc20.src.rpm
    INFO: mock.py version 1.1.32 starting...
    Start: init plugins
    INFO: selinux disabled
    Finish: init plugins
    Start: run
    INFO: mock.py version 1.1.32 starting...
    INFO: Start(ipset-6.20.1-1.fc20.src.rpm)  Config(fedora-rawhide-x86_64-modified-from-user-config)
    [... snip ...]
    INFO: Results and/or logs in: /var/lib/mock/myresultdir
    INFO: Cleaning up build root ('clean_on_success=True')
    Start: lock buildroot
    Start: clean chroot
    INFO: chroot (/var/lib/mock/fedora-rawhide-x86_64-modified-from-user-config) unlocked and deleted
    Finish: clean chroot
    Finish: lock buildroot
    Finish: run


The code to do that was added in this commit:

    commit 774154639a8b01ff32c2a4857e0cb322f54833fb
    Author: Masatake YAMATO <yamato>
    Date:   Thu Jun 7 14:29:21 2012 -0500
    
        added option to set a plugin parameter value from the commandline [BZ# 754321]
        
        This patch adds the --plugin-option command line option, which allows
        a plugin parameter to be set on the commandline:
        
        Ex:   mock --plugin-option="ccache:max_cache_size=5G" foo.src.rpm
        
        The above will set the cccahe max to be 5 gigabytes
        
        Signed-off-by: Clark Williams <williams>

Given that the commit message doesn't mention user configurations at all, I have a feeling that this wasn't expected to be committed, as if Masatake just added this to test his patch, and forgot to remove it (or to send it as a separate change)

So, Marcin, good news: you can already use a per-user configuration. :-)

(I still think it would be better in ~/.config/mock/, though)

-----

Now to the other part of your question: can we use variables in the config so that, for example, the resultdir would be defined relatively to the package name/version?

Not at the moment, because the configs are read long before mock starts looking at the srpm to build.

In py/mockbuild/backend.py, the resultdir is obtained with this line:

    self.resultdir = config['resultdir'] % config

So maybe if py/mock.py could proactively add the package name and version to the config, then it should all just work.

However, the problem is that mock doesn't always have a package to process. For example, when running the "--init" command, mock still needs to write the log files into the resultdir. But because there is no package associated, then the resultdir string wouldn't be interpolated properly, and as a result mock would store the logs in a folder like 
/path/to/my/resultdir/%(package_name)-%(package_version)" which doesn't strike me as highly desirable.

So given all this, maybe this isn't such a good idea, and the best really is to specify --resultdir on the command line?

Note that the above is what I got from reading the code, but I don't know it that well and could very well be wrong :)

Comment 5 Clark Williams 2013-12-13 20:52:31 UTC
That looks like a good summary. 

I do like the idea of moving configs into ~/.config/mock so if you want to gin up a patch for that feel free. 

You *can* use variables in the config, but as you point out it's a hit-or-miss thing based on how mock was invoked. Of course you can create your own configs or edit existing configs and put reasonable (for you) defaults into them.

Given all that I'd probably say it's safer to just specify the resultdir on the command line.

Comment 6 Marcin Juszkiewicz 2014-01-14 13:04:39 UTC
Thanks for feedback guys. Looks like I will stay with my build scripts then.

Comment 7 Miroslav Suchý 2014-07-07 14:33:52 UTC
So what is status of this RFE? Do you still want it? Or the findings in #4 is enough?

Comment 8 Marcin Juszkiewicz 2014-07-28 14:54:03 UTC
CLOSED/TOBEIGNORED would be best.

I looked at comment #4, created ~/.mock/user.cfg but it is far from what I had in pbuilderrc under Debian. Those tools differ too much so I will stay with my scripts around mock as they are good workarounds for existing code.

Note that I use mock only to build packages. So all I want is "take this srpm, build, drop into shell if failed" which my script does:

--------------------------------------------------------------------------
$ cat ~/bin/hrwmock.sh 
#!/bin/bash

SRCRPM=`realpath $1`
PACKAGENAME=`basename $1`

X=X
LC_ALL=C LANG=C mock $SRCRPM \
        --resultdir=~hrw/rpmbuild/mock/$PACKAGENAME \
        --verbose \
        --no-cleanup-after \
        --uniqueext=$PACKAGENAME && X=Y

if [ $X == X ]; then
        echo ""
        mock --shell --uniqueext=$PACKAGENAME
fi

mock --clean --uniqueext=$PACKAGENAME
--------------------------------------------------------------------------

This way I can have several builds going at same time as they do not reuse the same chroot and build dir is dropped after build of package. I also use squid with few GB of on-disk cache instead of yum caching.


Note You need to log in before you can comment on or make changes to this bug.