summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorintrigeri <intrigeri@boum.org>2011-04-16 18:56:28 +0200
committerintrigeri <intrigeri@boum.org>2011-04-16 18:56:28 +0200
commit10602edc351d8eb3fbb54a50e079a568c15869e0 (patch)
treeca0e4872d86b330c2ce59484aeff634fc8683d18
parenta097d9874137eeaccbd25a5fa525461fc0fd3ebd (diff)
Reply.
-rw-r--r--doc/bugs/yaml_setup_file_does_not_support_UTF-8_if_XS_is_installed.mdwn22
1 files changed, 22 insertions, 0 deletions
diff --git a/doc/bugs/yaml_setup_file_does_not_support_UTF-8_if_XS_is_installed.mdwn b/doc/bugs/yaml_setup_file_does_not_support_UTF-8_if_XS_is_installed.mdwn
index da8f494ff..df27fa481 100644
--- a/doc/bugs/yaml_setup_file_does_not_support_UTF-8_if_XS_is_installed.mdwn
+++ b/doc/bugs/yaml_setup_file_does_not_support_UTF-8_if_XS_is_installed.mdwn
@@ -38,3 +38,25 @@ preferred one?
>> Syck earlier.) So it appears the new YAML::Xs is the
>> way to go longterm, and presumably YAML::Any will start depending on it
>> in due course? --[[Joey]]
+
+>>> Right. Since this bug is fixed in current testing/sid, only
+>>> Squeeze needs to be taken care of. As far as Debian Squeeze is
+>>> concerned, I see two ways out of the current buggy situation:
+>>>
+>>> 1. Add `Conflicts: libyaml-libyaml-perl (< 0.34-1~)` to the
+>>> ikiwiki packages uploaded to stable and squeeze-backports.
+>>> Additionally uploading the newer, fixed `libyaml-libyaml-perl`
+>>> to squeeze-backports would make the resulting situation a bit
+>>> easier to deal with from the Debian stable user point of view.
+>>> 2. Patch the ikiwiki packages uploaded to stable and
+>>> squeeze-backports:
+>>> - either to workaround the bug by explicitly using YAML::Syck
+>>> (yeah, it's deprecated, but it's Debian stable)
+>>> - or to make the bug easier to workaround by the user, e.g. by
+>>> warning her of possible problems in case YAML::Any has chosen
+>>> YAML::XS as its preferred implementation (the
+>>> `YAML::Any->implementation` module method can come in handy
+>>> in this case).
+>>>
+>>> I tend to prefer the first aforementioned solution, but any of
+>>> these will anyway be kinda ugly, so...