1 |
On 02/24/2010 02:15 AM, Doug Goldstein wrote: |
2 |
> My response was the arch teams haven't stabilized MythTV in years |
3 |
> because none of them have a setup to test it, so please stabilize it. |
4 |
> I'm running it on a stable machine. |
5 |
|
6 |
Well, to their credit, you CAN'T stabilize a package if you can't test |
7 |
it. I can test it and stabilize it on amd64, but that's it. If there |
8 |
is an arch that nobody has a mythtv setup for testing on then the |
9 |
solution is to drop the stable keyword entirely - not to just mark it |
10 |
stable. |
11 |
|
12 |
> As far as the news item goes, as I've said before. Its completely |
13 |
> unnecessary since MythTV will handle notifying you properly if you |
14 |
> need to do anything to your database. I can count more than a dozen |
15 |
> people on Gentoo that have successfully done the conversion without |
16 |
> issue. |
17 |
|
18 |
Here is the problem I have with this: doing the migration takes time. |
19 |
Somebody who does an emerge -u world probably doesn't set aside an hour |
20 |
or two to manually fix databases. Anybody doing this for mythtv will at |
21 |
best have a mythtv install that refuses to start until they spend time |
22 |
doing database dumps, sed scripts, and reloads. If for some reason the |
23 |
mythbacked doesn't detect the problem and starts up anyway, then they'll |
24 |
end up with partial database corruptions. |
25 |
|
26 |
I think that if nothing else we should send out a news item warning |
27 |
users that a major mythtv upgrade is coming and that they should |
28 |
exercise care in upgrading it, setting aside time for database cleanup |
29 |
if they are long-time users. I'm completely open to revised wording, |
30 |
but I don't feel comfortable stabilizing this for amd64 without any news |
31 |
at all. |
32 |
|
33 |
I do appreciate all you've done for mythtv, and the time crunch you are |
34 |
in right now. However, if I commit a keyword stabilization I need to be |
35 |
accountable for the results. I suspect the other arch teams feel |
36 |
similarly - nobody wants to just commit something like this without |
37 |
testing and good documentation. |
38 |
|
39 |
How about this revised news item: |
40 |
|
41 |
Title: MythTV 0.22 Upgrade Database Corruption |
42 |
Author: Richard Freeman <rich0@g.o> |
43 |
Content-Type: text/plain |
44 |
Posted: <date> |
45 |
Revision: 1 |
46 |
News-Item-Format: 1.0 |
47 |
Display-If-Installed: <media-tv/mythtv-0.22 |
48 |
|
49 |
Due to an incompatibility between MythTV 0.21 and the default Gentoo |
50 |
MySQL configuration, it is likely that long-time MythTV users will have |
51 |
databases with a mixture of locale encodings. If you upgrade to 0.22 |
52 |
without following these directions carefully, you could end up with a |
53 |
database that contains errors that are extremely difficult to fix. |
54 |
|
55 |
Note that not all mythtv users need to modify their databases, and this |
56 |
should only be performed at the time of the upgrade. The guide below |
57 |
contains instructions that can be used to determine if this problem |
58 |
pertains to you. |
59 |
|
60 |
Please see the MythTV Upgrade Guide for instructions: |
61 |
|
62 |
http://wiki.mythtv.org/wiki/Fixing_Corrupt_Database_Encoding |
63 |
|
64 |
Be sure to save a database backup before upgrading. Also, be sure to |
65 |
upgrade any other clients/backends you are using to 0.22 at the same |
66 |
time. The upgrade instructions need to be followed once per database - |
67 |
individual client/backend upgrades do not require these steps. |
68 |
|
69 |
If you do run into problems with your upgrade, there is a forum thread |
70 |
where you may be able to find help: |
71 |
|
72 |
http://forums.gentoo.org/viewtopic-t-816566-highlight-.html |