restore binary mtime after debug package creation

devzero2000 pinto.elia at gmail.com
Fri Jul 27 12:39:04 UTC 2012


On Fri, Jul 27, 2012 at 6:04 AM, Alfred Landrum <alfred.landrum at riverbed.com
> wrote:

>  Hi rpm folks -
>
>  I'm using rpm 4.9 and redhat-rpm-config 9.0.3 on a scientific linux 6
> based system.  I'm writing a spec file for a package that's used during
> development; it needs to contain both headers & a binary utility.
>
>  When debug package creation runs at the end of %install, it strips the
> binary utility, causing an update to its mtime.  Since the headers are
> untouched, that means that the binary utility looks newer than the headers
> – which ends up throwing off some makefiles later on.
>
If you are only packaging binary file you probably don't want to create
useless debuginfo package or strip anything. In this case could be useful
to define in your spec these macros

# Don't try fancy stuff like debuginfo, which is useless on binary-only
    # packages. Don't strip binary too
    # Be sure buildpolicy set to do nothing
    %define        __spec_install_post %{nil}
    %define          debug_package %{nil}
    %define        __os_install_post %{_dbpath}/brp-compress

(i have written this some time ago
stackoverflow.com/questions/880227/what-is-the-minimum-i-have-to-do-to-create-an-rpm-file
 <http://stackoverflow.com/questions/880227/what-is-the-minimum-i-have-to-do-to-create-an-rpm-file%20>)

If instead you want anyway the debuginfo and strip the binary but
preserve timestamp define

%global __strip strip -p # in the spec
%__strip strip -p           #  in ~/.rpmmacros

hth





>
>  I'd like to have all the files have the same mtime, but unsure of how to
> make a "set all times" shell action that runs after everything else in
> __spec_install_post (including debug package creation).  Any suggestions?
>
>  Thanks - Al
>
> _______________________________________________
> Rpm-list mailing list
> Rpm-list at lists.rpm.org
> http://lists.rpm.org/mailman/listinfo/rpm-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-list/attachments/20120727/cea9beba/attachment.html>


More information about the Rpm-list mailing list