Red Hat Bugzilla – Bug 230412
No src.rpm available for mysql
Last modified: 2013-07-02 23:12:08 EDT
Description of problem:
There is no src.rpm available for mysql 5.0.30, as released in the RHWAS with
the last CVE fix
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. read errata http://rhn.redhat.com/errata/RHSA-2007-0083.html
2. check updates SRPMS dir at
no mysql package is listed.
mysql src.rpm package is listed.
Not sure if this is the proper place to file the bug, but I don't see a RHWAS
area in bugzilla.
RHWAS is not distributed via ftp.redhat.com. You can find the SRPM on RHN or on
the ISO image for the Stacks 1.1 product (ie, same places you can get the
There seems to be a miscommunication somewhere then, because
has the other src.rpms listed, including the recent php updates. The only one
missing is mysql. (and the java-bea files which is expected)
probably also worth noting that the announcement to the enterprise watch list
specifically linked to the ftp location for the src.rpm. See ->
As per comment #2, the SRPMS are up on the web for everything except the mysql
I need to confirm the reason why the mysql RPM isn't there, and I shall post
back to this bug with that info when I can.
This is the repsonse that I have gotten from some of the business/product guys
who work on the Application Stack. I am relaying it here:
Red Hat has a support & distribution agreement in place with MySQL (the company)
that is specific to the Application Stack only.
MySQL now has two versions of their product: MySQL Community (al la Fedora) and
MySQL Enterprise (al la RHEL); in the Application Stack, we ship MySQL
Enterprise and make the source available to customers via RHN.
The rest of the Application Stack, we make the source available via RHN and also
via public websites.
At this time, MySQL has advised us that they only want us to distribute the
MySQL Enterprise source to Application Stack subscribers (only). Our
business/product guys are working on breaking this barrier down so that we're
more consistent with the other Stack components, because we want to be able to
distribute the mysql RPM just like everything else.
I know that's not a wonderful answer, but it's the truth.
Hey, an answer is an answer and I'm happy to have one rather than guessing. This
does however raise a few more questions.
If this is the enterprise version vs the community version, why are they named
in identical fashion? Why not a mysql-enterprise, or mysql-community pack so
folks know which they've got?
Also, I was under the impression that mysql enterprise was more support than
license. What license is the mysql enterprise in RHWAS released under?
Why will no one answer this question?
That is the update that is listed on the errata for RHWAS 4AS ///
I find it hard to believe that since the RPM names are identical that the SRPM
was released other than GPL.
Is it now RH policy that you will not provide GPL'ed SRPMS to people who ask?
Is mysql-5.0.30-1.el4s1.1.src.rpm not GPL ???
Taking this one step further still ...
That is the version in RHWAS beta ... and that is released via GPL.
So is someone going to tell me that RedHat did change the license for
mysql-5.0.30-1.el4s1.1.src.rpm and that it is no longer GPL.
If it is GPL (and I fully expect that it is) then should Red Hat not follow it's
policy of making that SRPM available as it does all other GPL SRPMS?
As per comment #5, this is not our choice, it is MySQL AB's. Complain to them.
OK ... how can that be.
The only file (at least from mysql-5.0.18-4.el4s1.1.src.rpm) that MySQL AB
supplies is the .tar.gz file. That file was available from
ftp://ftp.mysql.com/pub/mysql/src ... as are all the newer ones now.
How can they possibly then not allow you to release the SRPM.
Those files are all GPL ... how can they "restrict" the release of any
distributive works in any way.
I certainly will contact MySQL AB if you really want me to. Of maybe just the FSF.
MySQL AB operates under a dual license; some versions of what they ship are GPL, and some are not. You
can complain all you like, but that does not make it right for us to violate their license terms.
For the record, there's no GPL violation here. It would be a GPL violation if we made binaries available
without corresponding source. The RHWAS versions of mysql are available to RHWAS subscribers ---
source and binaries both. There's nothing in the GPL that says we must make them available to the entire
As a grunt engineer, I'm not especially pleased with this situation either. But it is not illegal or against the
terms of any license. And it is what is required by MySQL AB for us to ship the "enterprise" releases of
their code at all. So, again, they're the people to complain to.
We've raised this question again to the mySQL folks. Here's what we got back
1) They thought that what I wrote in comment #5 was still pretty accurate.
That's not surprising, because we asked them to help us understand what was
going on before I wrote it.
2) They are happy to interact directly with folks on this bugzilla, either by
contacting "license-feedback AT mysql.com" or Colin Charles "colin AT
mysql.com", who is the community relations manager.
I like that idea because then I'm not the public middle-man anymore :-)
Wouldn't it be possible to publish the SRPM without including the source tarball
itself? AFAIK RPM provides a "Nosource:" directive that tells RPM to skip a
source file from the source RPM. This way Red Hat could provide the SRPM without
violating any agreement.
That's a fairly strange definition of "providing the SRPM" ... I don't believe that such a thing would even
work in Red Hat's own build system, let alone satisfy the complainants.
Well, if you combine the "Nosource" SRPM from Red Hat with the source tarballs
that are provided by MySQL AB at the location mentioned in Comment #11, you get
all you need to rebuild a binary RPM. Why do you think this would not resolve
Granted, I don't know the Red Hat build system, but does it really use the SRPMs
to compile binary RPMs? I would assume it uses the plain spec files, patches and
source tarballs as input for the binary builds - the SRPMs are just byproducts.
(In reply to comment #15)
> That's a fairly strange definition of "providing the SRPM" ... I don't believe
that such a thing would even
> work in Red Hat's own build system, let alone satisfy the complainants.
Really, my original concern was that packages were listed as resolving cve's
with an address to the ftp site, where no package existed. It seemed an
oversight that someone had not posted the packages, or was intentionally leaving
them out as all the other src.rpms seemed to have been posted.
Now that we've established that there are license issues in the works, my
question was more of an implementation one, as there are now multiple versions
of differently licensed mysql packages in play.
1. The original GPL'd mysql in the base distribution
2. The MySQL-AB licensed mysql in the RHWAS channel.
Both packages are named the same way, so this could potentially create confusion
amongst the user-base. Granted the likelihood of this is next to nil, but it
does become a possibility.
(In reply to comment #16) No, the Red Hat (and Fedora) build process involves constructing an SRPM from
our package CVS plus upstream tarballs, then building binary RPM(s) from the SRPM in a minimal
buildroot. This is to ensure that the package has no undocumented dependencies and actually can be
rebuilt from what the specfile claims. The entire process is designed to ensure that we *can't* ship
Tom, thanks for the explanation. I agree, in this case a "Nosource:" RPM is
probably not an option. Well, it was worth a shot :)
In any case I agree that the RPMs built from the MySQL Enterprise sources should
probably be renamed to "mysql-$subpackage-enterprise", with the appropriate
"Provides"/"Obsoletes" directives in place to make an update from the previous
packages possible in a painless way. The MySQL Enterprise RPMs built by MySQL AB
use similar names.
*** Bug 517788 has been marked as a duplicate of this bug. ***
Yes, if these packages really are separated as enterprise vs community, they should be identified as such.
for experimentation, would it be possible for someone at redhat to put up the spec and patch files so we could try to build from that?
5.0.84 was just released in rhwas 2.4.
Actually, this bug is going to get closed real soon now: we are no longer shipping the enterprise version of mysql, but the community version, so the licensing restrictions no longer apply. I'm just waiting for release engineering to turn the crank and then the SRPM should appear in the normal place.
Good news! Any rough estimate for an ETA on this one? Not to sound too overly demanding, but this bug's been open a while
I don't have control over releng's schedule, but I imagine it will get dealt with as soon as they don't have any high-priority fires to fight ... I'm expecting days not weeks.
OK, it's up: see http://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/RHWAS/SRPMS/