Fedora 11 Mass Rebuild

Josh Boyer jwboyer at gmail.com
Wed Feb 18 20:16:56 UTC 2009


On Wed, Feb 18, 2009 at 01:30:45PM -0600, Matthew Woehlke wrote:
> Josh Boyer wrote:
>> On Wed, Feb 18, 2009 at 10:59:12AM -0600, Matthew Woehlke wrote:
>>> Jesse Keating wrote:
>>>> On Tue, 2009-02-17 at 20:42 -0500, Jon Masters wrote:
>>>>> And what will happen when something wants a static
>>>>> library file to link against?
>>>> This one is a little bit more interesting, perhaps everything that is
>>>> static should get a second rebuild pass.  Of course, now I'm going to
>>>> want a good programmatic way of discovering what is statically compiled,
>>>> preferably without having to look at the binaries themselves.
>>> It needs more resources, but the obvious solution is to do what gcc   
>>> does... rebuild *everything* twice, and remove from the rebuild list  
>>> things that produced an identical package. Then do a third pass, and  
>>> continue until nothing changes. (Probably it will be necessary to 
>>> scan  the rebuild list between subsequent packages to cull things 
>>> that are  only "changed" due to timestamps and the like.)
>>>
>>> This should catch everything where a rebuilt dependency caused the   
>>> resulting package to be different.
>>
>> The simple act of rebuilding the packages will change them.  You'll
>> always get a difference, given that the RPM header will change and
>> the Release number will be bumped.
>
> Obviously you'd need a way to exclude these differences.
>
>> Even ignoring the RPM parts, various applications do things like
>> embed dates or buildhosts or other build time information into the
>> binaries, and will differ as a result of that.
>
> Of course. That's why, if you read *all* of my previous message, I said  
> "probably it will be necessary to scan the rebuild list between  
> subsequent packages to cull things that are only "changed" due to  
> timestamps and the like."

Excellent.  Sounds like you know what you're doing already.

I look forward to seeing the code that accomplishes what you suggest.

josh




More information about the devel mailing list