Wednesday, August 13. 2008
MySQL 5.0.67 not uploaded to Debian
Last weekend I updated the Debian package of MySQL to 5.0.67, the latest Community Edition release. It was not uploaded into the Debian archive, but is available from my home directory on gluck (amd64 only at the moment). The next Debian release lenny is frozen already, which means no newer upstream releases get accepted into testing before lenny is released, hence lenny definitely gets shipped with MySQL 5.0.51a. We will not see MySQL 5.0.67 or 5.1 in lenny, but we will continue providing backports of newer MySQL releases.
Our current primary goal regarding the MySQL packages in Debian is to get 5.0.51a in shape for lenny, so please do not send us mails asking about MySQL 5.1 or MySQL Cluster. When lenny got released we will upload MySQL 5.0.67 (or any newer community release) to unstable, and will then take care of MySQL 5.1 and MySQL Cluster.
Our current primary goal regarding the MySQL packages in Debian is to get 5.0.51a in shape for lenny, so please do not send us mails asking about MySQL 5.1 or MySQL Cluster. When lenny got released we will upload MySQL 5.0.67 (or any newer community release) to unstable, and will then take care of MySQL 5.1 and MySQL Cluster.
Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
Why backport? Debian cannot trust in the upstream developers of MySQL?
Of course we trust the upstream MySQL developers. What I meant with "backport" is a recompiled package from the Debian development distribution for the actual stable distribution.
Ok, I'm happy a Debian developer answers me.
I'd like to ask you a few more questions.
Why Debian provides Apache 2.2.3-4+etch5 instead of 2.2.9 in Etch?
It's only security fixes, ok, but 2.2.9 isn't stable enough? The Apache Foundation is not like it was new developers. They are really strong. Furthermore, if the Debian security made mistakes while backporting, it's unlikely that it will be discovered, since all the audit is done in the upstream version.
Well, apache is really a critical application so I could understand, but what I really don't understand, it's that you do the same thing for The Gimp (2.2.13-1etch4 in Etch, 2.2.17 for upstream).
I'd like to ask you a few more questions.
Why Debian provides Apache 2.2.3-4+etch5 instead of 2.2.9 in Etch?
It's only security fixes, ok, but 2.2.9 isn't stable enough? The Apache Foundation is not like it was new developers. They are really strong. Furthermore, if the Debian security made mistakes while backporting, it's unlikely that it will be discovered, since all the audit is done in the upstream version.
Well, apache is really a critical application so I could understand, but what I really don't understand, it's that you do the same thing for The Gimp (2.2.13-1etch4 in Etch, 2.2.17 for upstream).
It is because of changes in new upstream releases like MySQL bug #25365. You do not want such changes on production servers, it could break your applications.
I agree that a difference could be made between server and desktop related packages, but that is not the case in Debian. A stable Debian release comes with an upstream version x.y.z, and in most cases (Mozilla products are an exception in Debian) this release will be kept over the whole lifetime of the Debian release, and security fixes will get backported. Most big Linux vendors are using such a release model.
I agree that a difference could be made between server and desktop related packages, but that is not the case in Debian. A stable Debian release comes with an upstream version x.y.z, and in most cases (Mozilla products are an exception in Debian) this release will be kept over the whole lifetime of the Debian release, and security fixes will get backported. Most big Linux vendors are using such a release model.
"I agree that a difference could be made between server and desktop related packages"
Why don't you suggest it to the other developers?
"Most big Linux vendors are using such a release model."
Yes, but they have money, workers, and they have less packages than Debian.
Even for the server side, if two applications do the same things, you could freeze one as usual (only backport of security fixes), and not for the other.
Why don't you suggest it to the other developers?
"Most big Linux vendors are using such a release model."
Yes, but they have money, workers, and they have less packages than Debian.
Even for the server side, if two applications do the same things, you could freeze one as usual (only backport of security fixes), and not for the other.
That is not a new idea, it was discussed a thousand times on the debian-devel mailinglist. :-)
I think it is a lot easier to just apply a small security fix if you know what it exactly does, than updating a package to a new upstream release, and make sure that it really works together with other packages and does not break anything.
I think it is a lot easier to just apply a small security fix if you know what it exactly does, than updating a package to a new upstream release, and make sure that it really works together with other packages and does not break anything.
It's not a new idea, but it never changed.
You satisfy a minority, enterprises which need stability, instead of the normal users. Because -testing or -backport are not practical.
It's a matter of priorities. Instead of providing backports, you could do a project like Debian kfreebsd which provides frozen applications with only security fixes.
So we could have apache 2.2.9 and let the upstream stabilizes its software the way it wants, and for those who needs stability, they could have apache 2.2.3.frozen6.
It's a lot simpler this direction.
You satisfy a minority, enterprises which need stability, instead of the normal users. Because -testing or -backport are not practical.
It's a matter of priorities. Instead of providing backports, you could do a project like Debian kfreebsd which provides frozen applications with only security fixes.
So we could have apache 2.2.9 and let the upstream stabilizes its software the way it wants, and for those who needs stability, they could have apache 2.2.3.frozen6.
It's a lot simpler this direction.
Sounds a bit like what we are providing on http://backports.org/ already.
No, I said the opposite.
I suggested to delete backports.org, because for the non-essential applications you could upgrade to the latest version in -stable directly, and then for those who really need another kind of stability, you could provide a 'frozen.org'.
I suggested to delete backports.org, because for the non-essential applications you could upgrade to the latest version in -stable directly, and then for those who really need another kind of stability, you could provide a 'frozen.org'.
Indeed that would be nice for desktop system, but I am sure Debian runs on a lot more server systems than desktop systems, so the way we actually go is the better way for most of our users. Debian can not make everyone happy. :-)
Maybe that is why Ubuntu is so successful on desktop systems.
Maybe that is why Ubuntu is so successful on desktop systems.
Ok, it's a good argument. But not all DDs think Debian should let the desktop to Ubuntu, and a lot think Debian is "the Universal operating system".
You should have a definite goal once and for all, because nothing is clear.
You should have a definite goal once and for all, because nothing is clear.
I'd like to add that you are an operating system. If MySQL or the Apache Foundation broke something in their -stable branches, it is their problems.
But as an operating system, what is important it's that you care about e.g the Linux kernel and backport security fixes for it.
But as an operating system, what is important it's that you care about e.g the Linux kernel and backport security fixes for it.
Pointing fingers would not help our users, when their applications break because of a bug (or a changed behaviour) in a new upstream release.
You can have like in gentoo a testing branch, but for each application (~).
Furthermore, if an application breaks:
1) It's not as important than an essential library.
2) One can simply downgrade until the upstream finds the problem!
Furthermore, if an application breaks:
1) It's not as important than an essential library.
2) One can simply downgrade until the upstream finds the problem!
Not possible, because of conflicting package names with mysql-dfsg-5.1 which already is in experimental.
Quicksearch
Calendar
|
September '10 | |||||
| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | |||
Categories
Syndication
Personal
Blogroll
