Re: [Rdkit-devel] RDKit changes for RHEL/CentOS 5 packaging

[Gianluca S. <gi...@gm...>]

Thanks Greg for the comments, I was carried away for a while, but now
I'll need to update my production servers and I'll work a bit more on
this.

On Thu, May 19, 2011 at 5:29 AM, Greg Landrum <gre...@gm...> wrote:
> I guess I don't really understand how the RHEL guys decide when to
> update a package. Neither bison nor boost are particularly exotic
> pieces of software and both are quite widely used, yet the versions of
> each that are available with these systems is really out of date.

Didn't check bison, but the general idea is that you stick with a base
version for the lifetime of the product and only fix stuff that's
broken; that's the only way to have something that builds and works at
the original release continue working after upgrades.

For instance, if you built and deployed a PHP web application with a
CentOS 5 server you had PHP 5.1.6. You don't want your application to
break because the (incompatible) PHP 5.3 package landed in the
repositories. Yes, that's unfortunate if you want to deploy a new
application requiring PHP 5.3, so they needed to introduce a php53
package in CentOS 5.6 (I guess, due to popular demand).

Flex is in a similar situation: it seems the versions after 2.5.4 were
not 100% compatible, so they could not upgrade. I bet the same is true
for boost.

In short, RHEL is for mission critical infrastructure. That's probably
the reason why more desktop oriented users find it a weird platform to
work on.

>
>> It turned out the
>> only feature used from the newer boost is the BOOST_FOREACH construct
>> (there were about 30 in the whole code base), so I just had to
>> routinely replace it with a regular for loop on the proper iterators.
>
> Lovely. I've been doing the opposite (replacing standard for loops
> with BOOST_FOREACH) whenever I'm working in a file and remember to do
> so. It makes for somewhat cleaner code.

:-)

>
> - There was a change in the boost random number generator in version
> 1.40. This means that fingerprints generated with v1.40 and beyond are
> not compatible with earlier versions. This is likely to lead to
> confusion

Ok, I'd need more info about this. Are you aware if the change was due
to a bug or some other reason? Do you know if we can we do something
on our side to make the behavior consistent?

By the way, I noted 1.39 is required in CMakeList.txt, which is the
first release that supported BOOST_FOREACH


>
> - RHEL is still shipping with only python2.4 available, right? This is
> probably also going to be a problem.

Right, I have python 2.4 there; any specifics about what you expect
breaking with it? Right now the only failing tests I have (more on
this later) look like related to the aforementioned random number
generator changes.
If really needed I can make the package require python26, which is
available in EPEL.


-- 
Gianluca Sforna

http://morefedora.blogspot.com
http://identi.ca/giallu - http://twitter.com/giallu