Bug 1168911 - RFE: install package after successful build
Summary: RFE: install package after successful build
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: mock
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Miroslav Suchý
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-11-28 12:01 UTC by Honza Horak
Modified: 2015-02-20 00:33 UTC (History)
7 users (show)

Fixed In Version: mock-1.2.6-1.el6
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-01-21 23:09:09 UTC


Attachments (Terms of Use)
new option --postinstall (4.65 KB, patch)
2014-11-30 11:19 UTC, Mikhail Campos
no flags Details | Diff
new option --postinstall, fixed logic (6.45 KB, patch)
2014-12-03 11:01 UTC, Mikhail Campos
no flags Details | Diff
new option --postinstall, fixed logic and suffix checking (6.45 KB, patch)
2014-12-03 11:09 UTC, Mikhail Campos
no flags Details | Diff

Description Honza Horak 2014-11-28 12:01:20 UTC
In most cases a successfully built package should be install-able in the same buildroot. There are cases it is not possible because packager made some mistake and he finds it out after testing or in the worse case after making it public. 

If mock tried to install all successfully built packages right after build, in the same buildroot, it would help to spot the issues sooner.

In other words, it is a new additional step in the build process.

It may be implemented as a plugin or as a new argument.

But since there are packages that are not possible to install right away and it is expected (e.g. because some bootstraping is necessary), failing to install the package should not cause the whole build to fail.

The warning could only be added into the build.log.

Comment 1 Mikhail Campos 2014-11-30 11:19:10 UTC
Created attachment 962905 [details]
new option --postinstall

Proposed patch attached.

Notes:
1) can not reinstall packages with the same version-release fields
2) can break build reusability in the same chroot

Comment 2 Miroslav Suchý 2014-12-01 08:42:37 UTC
Mikhail, thanks for the patch it is quite good. But I would like to see it implemented little bit differently.

When --noclean --postinstall is set, then buildroot is not cleaned and packages are installed (this is nearly what you implemented in your patch).
When just --postinstall is set, then after building buildroot is cleaned and only then package is installed. This can help find missing deps, which you may miss if you specify them as BuildRequires.

May I ask you please to alter your patch the way I just describe, please?

And one more note. This:
  pkgs = [pkg for pkg in results if not pkg.endswith(".src.rpm")]
should be rather:
  pkgs = [pkg for pkg in results if not pkg.endswith("src.rpm")]
Because there can be even no src packages, which have suffix *.nosrc.rpm"
See e.g.: http://www.unixcook.com/~hubba/blog/archives/2011/09/nosrcrpm-files.html

Comment 3 Mikhail Campos 2014-12-02 11:32:37 UTC
(In reply to Miroslav Suchý from comment #2)

> When --noclean --postinstall is set, then buildroot is not cleaned and
> packages are installed (this is nearly what you implemented in your patch).
> When just --postinstall is set, then after building buildroot is cleaned and
> only then package is installed.

I am not sure clear understood 'building buildroot is cleaned', which of them? Previous buildroot at the start building, or current at the end ? Do you mean that --postinstall option should work only, when --no-clean is NOT specified, in other words assume that packages already installed? Should we call post_install in a way "createrepo_on_rpms" called, after "cleanup_on_success" (rebuild_generic)?

Comment 4 Miroslav Suchý 2014-12-03 07:45:54 UTC
mock --postinstall --noclean:
  package is build, then package is installed into buildroot

mock --postinstall
  buildroot is cleaned, package is build, buildroot is cleaned again, package is installed

Comment 5 Mikhail Campos 2014-12-03 11:01:46 UTC
Created attachment 964082 [details]
new option --postinstall, fixed logic

New patch attached

Comment 6 Mikhail Campos 2014-12-03 11:09:25 UTC
Created attachment 964094 [details]
new option --postinstall, fixed logic and suffix checking

Sorry, missed correct suffix checking

Comment 7 Miroslav Suchý 2014-12-03 12:39:19 UTC
Looks good to me. But there are two issues:

a) it does not apply clean on master. It seem you are using some old branch. Can you please rebase it?

we user origin/master from:
​git://git.fedorahosted.org/git/mock.git

b) instead of 
+            if buildroot.chroot_was_initialized:
+                commands.install_build_results(commands.build_results)
+            else:
+                commands.init()
+                commands.install_build_results(commands.build_results)
+                commands.clean()
can you rather use:
+            if config_opts['clean']:
+                commands.init()
+                commands.install_build_results(commands.build_results)
+                commands.clean()
+            else:
+                commands.install_build_results(commands.build_results)

Comment 8 Mikhail Campos 2014-12-03 13:04:08 UTC
"if buildroot.chroot_was_initialized" is used for:

mock --rebuild /home/plageat/zlib-1.2.8-3.fc20.src.rpm --postinstall --cleanup-after --resultdir /tmp

Comment 9 Mikhail Campos 2014-12-03 13:24:55 UTC
Also I am using correct branch and can apply patch without problems.

Comment 10 Mikhail Campos 2014-12-03 14:09:11 UTC
Here is log:

[plageat@plageator mock]$ git clone git://fedorahosted.org/git/mock.git mock
Cloning into 'mock'...
remote: Counting objects: 10994, done.
remote: Compressing objects: 100% (6683/6683), done.
remote: Total 10994 (delta 7446), reused 6284 (delta 4255)
Receiving objects: 100% (10994/10994), 1.84 MiB | 17.00 KiB/s, done.
Resolving deltas: 100% (7446/7446), done.
Checking connectivity... done.
[plageat@plageator mock]$ wget https://bugzilla.redhat.com/attachment.cgi?id=964094
--2014-12-03 17:06:33--  https://bugzilla.redhat.com/attachment.cgi?id=964094
Resolving bugzilla.redhat.com (bugzilla.redhat.com)... 209.132.183.69
Connecting to bugzilla.redhat.com (bugzilla.redhat.com)|209.132.183.69|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 6607 (6.5K) [text/plain]
Saving to: ‘attachment.cgi?id=964094’

100%[============================================================================================================>] 6,607       --.-K/s   in 0s      

2014-12-03 17:06:34 (22.9 MB/s) - ‘attachment.cgi?id=964094’ saved [6607/6607]

[plageat@plageator mock]$ cd mock/
contrib/ docs/    etc/     .git/    py/      scripts/ tests/   
[plageat@plageator mock]$ cd mock/
[plageat@plageator mock]$ git am ../attachment.cgi\?id\=964094
Applying: Added new option 'postinstall' [RHBZ#1168911]
[plageat@plageator mock]$ git branch
* master

Comment 11 Miroslav Suchý 2014-12-04 08:45:11 UTC
Mea culpa, I was doing review on notebook, which I rarely use and did not notice I'm in different branch.

> if buildroot.chroot_was_initialized
This means that buildroot was initialize (--init), which is done in py/mockbuild/buildroot.py:_init() and is always true if you get past the point of building package.

I agree that bind it to --cleanup-after is better, but that would be:
  if config_opts['cleanup_on_success']:
because 'cleanup_after' is not export to config_opts, but when it is True, then py/mockbuild/util.py does:
    if options.cleanup_after == True:
        config_opts['cleanup_on_success'] = True
        config_opts['cleanup_on_failure'] = True
Hmm but that would not work, when used together with --resultdir, because of:
    # can't cleanup unless resultdir is separate from the root dir
    rootdir = os.path.join(config_opts['basedir'], config_opts['root'])
    if mockbuild.util.is_in_dir(config_opts['resultdir'] % config_opts, rootdir):
        config_opts['cleanup_on_success'] = False
        config_opts['cleanup_on_failure'] = False

Comment 12 Mikhail Campos 2014-12-04 09:48:37 UTC
(In reply to Miroslav Suchý from comment #11)

> > if buildroot.chroot_was_initialized
> This means that buildroot was initialize (--init), which is done in
> py/mockbuild/buildroot.py:_init() and is always true if you get past the
> point of building package.

No, can be changed in buildroot.py:delete() back to False ( from clean() )

def delete(self):
   ...
   self.chroot_was_initialized = False
   ...

Comment 13 Mikhail Campos 2014-12-12 12:32:07 UTC
(In reply to Miroslav Suchý from comment #11)

> Hmm but that would not work, when used together with --resultdir

Also it would work in all cases, just chroot will not be reinitialized. 
Or is it expected some special action when --resultdir option set?

Comment 14 Miroslav Suchý 2014-12-12 16:29:57 UTC
Commited as ef2b839.
Thanks for contribution.

Comment 15 Fedora Update System 2015-01-16 09:56:46 UTC
mock-1.2.4-1.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/mock-1.2.4-1.fc21

Comment 16 Fedora Update System 2015-01-16 09:57:23 UTC
mock-1.2.4-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/mock-1.2.4-1.fc20

Comment 17 Fedora Update System 2015-01-16 10:01:09 UTC
mock-1.2.4-1.el7 has been submitted as an update for Fedora EPEL 7.
https://admin.fedoraproject.org/updates/mock-1.2.4-1.el7

Comment 18 Fedora Update System 2015-01-16 10:01:47 UTC
mock-1.2.4-1.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/mock-1.2.4-1.el6

Comment 19 Fedora Update System 2015-01-16 19:10:28 UTC
Package mock-1.2.4-1.el7:
* should fix your issue,
* was pushed to the Fedora EPEL 7 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=epel-testing mock-1.2.4-1.el7'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-0312/mock-1.2.4-1.el7
then log in and leave karma (feedback).

Comment 20 Fedora Update System 2015-01-21 23:09:09 UTC
mock-1.2.4-1.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 21 Fedora Update System 2015-01-27 03:04:39 UTC
mock-1.2.4-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 22 Fedora Update System 2015-01-28 15:20:41 UTC
mock-1.2.5-1.el7 has been submitted as an update for Fedora EPEL 7.
https://admin.fedoraproject.org/updates/mock-1.2.5-1.el7

Comment 23 Fedora Update System 2015-01-28 15:21:54 UTC
mock-1.2.5-1.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/mock-1.2.5-1.el6

Comment 24 Fedora Update System 2015-01-28 15:23:05 UTC
mock-1.2.5-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/mock-1.2.5-1.fc20

Comment 25 Fedora Update System 2015-01-28 15:24:15 UTC
mock-1.2.5-1.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/mock-1.2.5-1.fc21

Comment 26 Fedora Update System 2015-02-02 17:22:32 UTC
mock-1.2.5-1.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 27 Fedora Update System 2015-02-03 04:42:19 UTC
mock-1.2.6-1.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/mock-1.2.6-1.el6

Comment 28 Fedora Update System 2015-02-03 04:42:55 UTC
mock-1.2.6-1.el7 has been submitted as an update for Fedora EPEL 7.
https://admin.fedoraproject.org/updates/mock-1.2.6-1.el7

Comment 29 Fedora Update System 2015-02-03 04:43:46 UTC
mock-1.2.6-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/mock-1.2.6-1.fc20

Comment 30 Fedora Update System 2015-02-03 04:44:18 UTC
mock-1.2.6-1.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/mock-1.2.6-1.fc21

Comment 31 Fedora Update System 2015-02-09 05:29:34 UTC
mock-1.2.6-1.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 32 Fedora Update System 2015-02-15 02:55:57 UTC
mock-1.2.6-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 33 Fedora Update System 2015-02-20 00:32:44 UTC
mock-1.2.6-1.el7 has been pushed to the Fedora EPEL 7 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 34 Fedora Update System 2015-02-20 00:33:39 UTC
mock-1.2.6-1.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.


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