[Python-3000] Solaris support in 3.0?

[Guido van Rossum]

On 9/5/07, "Martin v. Löwis" <martin at v.loewis.de> wrote:
> > This is a combination question-and-status-report email.  The question
> > would be, what does the "somewhat" tag mean on Solaris support in the
> > release notes for 3.0a1, and does someone have a list of things that
> > don't work, or does that just mean it hasn't been tested?
>
> Not sure what "somewhat" means, but you can take a look at the build
> failures in the Solaris buildbot - this is what is "officially" known
> not to work.

The "somewhat" was my word -- I meant that when I last looked at the
Solaris buildbot, I saw a few failures; and also that I don't have
access to Sun hardware. And also what Martin says below. I'd be happy
though to replace "somewhat" with specific indications of h/w and s/w
versions if you are willing to commit to supporting these throughout
the 3.0 life cycle.

> As always with Solaris, there are several dimensions to be considered:
> - version (2.5,2.6,7,8,9,10,11); not sure what the oldest Solaris
>   version is that we still want to support.
> - compiler: gcc vs. SunPRO/Forte
> - 32 vs. 64 bits
> - SPARC vs. x86
>
> (not all combinations exist, but plenty)
>
> > If anyone wants more data on any of these particular failures, let me
> > know, otherwise I'm going to start working through the ones that fail
> > in 3.0 that don't fail in 2.6.  All of the _md5 failures are because
> > of the lack of SSL, so I'm not sure that the tests should be 'failing'
> > in this configuration.
>
> I think that's a serious issue to consider. As so much code now depends
> on OpenSSL, setup.py should try harder to find it. E.g. on the build
> slave, it can be found in /usr/sfw - not sure whether that is normal
> on a Solaris 10 installation, and not sure whether there is a
> Sun-provided OpenSSL on Solaris 8.
>
> Notice that the tests don't 'fail', they are skipped. There are also
> failing test cases, something that is more worrisome than a skipped
> test case.

Yes, this is a serious issue -- we are totally dependent on openssl
for computing MD5 checksums. Several modules use MD5 checksums
casually, and it's not good that these fail when openssl isn't
available (or if it's too old, like what happened on an ancient Red
Hat 7.3 system I have at home). I'm tempted to put the old
RSA-copyrighted md5.c back in as a fallback, even though its license
is impopular. Or perhaps we could make a copy of a small fraction of
openssl and use that? I think MD5 is the only one that's popular
enough to warrant this treatment; I think SHA1 is a distant second.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)