[CentOS-devel] FYI: centos reproduceability

Mike A. Harris mharris at mharris.ca
Tue Apr 28 09:37:41 UTC 2009


Les Mikesell wrote:
> James Antill wrote:
>>> just ot mention a few problem with 5.3:
>>> - openjava was added to the distro so all packages which requires
>>> java-devel now try to build with openjava in stead of gcc's java and
>>> most of them fail.
>>> - new updates like dbus-glib, ifd-gate, pccs etc have incompatible devel
>>> packages eg. headers, but not all of the packages requires these new
>>> packages was rebuild/fixed so those packages no longer build.
>>> - newer gcc, toolchain etc (which included in later updates) have
>>> stronger check and standard compliance but with these tools old and
>>> buggy code no longer compile.
>>  This is useless churn to rebuild all the packages to fix these kinds of
>> build differences, why do you think RH's customers would want them to do
>> that?
> 
> I thought _THE_ selling point of open source has always been that in 
> case of problems the vendor can't/won't fix, you have the option to make 
> the change yourself.  But if you can't rebuild their packages or even 
> tell how the source relates to the shipped binary, that isn't true and 
> shouldn't be represented as such.

It sucks that the latest sources do not compile on the OS they were 
originally built for, but the fact is that packages get built at a 
certain point in time against what is in the tree at that time.

Then packages continue to be updated to fix bugs, etc. and in some cases 
maybe even add a new feature here or there.  All it takes is for one of 
these updates to change something in such a manner that packages that 
depend on this package will no longer compile.  It could be as simple as 
a file being moved from one location to another, or some other innocent 
innocuous change.

The only way to prevent that sort of thing is to have a mandatory policy 
that whenever _any_ package is rebuilt in the distribution, that the 
entire distribution must be rebuilt in a tree with the absolute latest 
packages present just to ensure that all packages still compile.

What if they don't?  Are they going to be expected to rebuild all 
packages that don't build because of this, and have to release them all 
as updates?  That makes no sense whatsoever _except_ during the initial 
development phase of the OS - ie: rawhide.

Could the whole process be improved?  Absolutely.  Is it?  I think so. 
Just look at how Fedora policies and procedures have evolved since 
inception.  Look at how the build system has evolved.  Keep in mind that 
RHEL inherits from Fedora initially and so it also inherits all of the 
improvements done in this area.

As things stand right now though, the only way for anyone to 
successfully build any package that shipped with RHEL and have it 
successfully build, is to know the exact version of every package that 
was installed on the system that built the RHEL package successfully.  I 
don't know if that information is logged and/or kept or not but I 
suspect not.

So the distro is built against itself during development, but it isn't 
kept in a rolling state of 100% self-hostingness.  It would be nice if 
the latest packages always built against the current OS, but the cost of 
making it do that could be quite high, and easily result in tonnes of 
packages being issued as updates for no other reason than to make them 
compile again.

It's really just the nature of how everything builds together.  There 
are no conspiracies going on.  This problem will IMHO become less and 
less of an issue in the future as the buildsystem and policies continue 
to mature and evolve on the Fedora/Red Hat side of things.






More information about the CentOS-devel mailing list