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): 5.0.30 How reproducible: Always Steps to Reproduce: 1. read errata http://rhn.redhat.com/errata/RHSA-2007-0083.html 2. check updates SRPMS dir at http://ftp.redhat.com/pub/redhat/linux/updates/enterprise/4AS/en/RHWAS/SRPMS/ Actual results: no mysql package is listed. Expected results: mysql src.rpm package is listed. Additional info: 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 binaries). Try https://rhn.redhat.com/network/software/packages/details.pxt?pid=383021
There seems to be a miscommunication somewhere then, because http://ftp.redhat.com/pub/redhat/linux/updates/enterprise/4AS/en/RHWAS/SRPMS/ 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 -> https://www.redhat.com/archives/enterprise-watch-list/2007-February/msg00009.html
As per comment #2, the SRPMS are up on the web for everything except the mysql package. http://ftp.redhat.com/pub/redhat/linux/enterprise/4/en/RHWAS/ 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?
mysql-5.0.30-1.el4s1.1.i386.rpm c1bd8eae792b620677100762b2659dac mysql-bench-5.0.30-1.el4s1.1.i386.rpm 4a9671ac9a96e68d48a3c9aaf24e607d mysql-devel-5.0.30-1.el4s1.1.i386.rpm 81fc452e5a6849a88b6db218a5c92dc7 mysql-server-5.0.30-1.el4s1.1.i386.rpm af5162d98ff053a9e641c4284874a675 mysql-test-5.0.30-1.el4s1.1.i386.rpm 440229a542bf959f05cd22aa469948bb 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 ... mysql-5.0.18-4.el4s1.1.src.rpm 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 world. 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 from them: 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 the issue? 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 nonfunctional SRPMs.
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/