Free Culture

bact' คิดได้น่าสนใจ เกี่ยวกับวัฒนธรรมเสรี (free culture) โดยต่อเนื่องกับ blog เรื่อง Postcardware ของผม

ประเด็นของ bact' นั้นโดนใจ แต่ผมค่อนข้างจะมองในแง่ปฏิบัติ ก็เลยไม่ได้คิดไปไกลขนาดนั้นในบางเรื่อง

เรื่องการกำหนดให้ขออนุญาต ผมไม่คิดว่าเป็นเรื่องการต้องการทำหลายมาตรฐานโดยตรง แต่เห็นว่าเป็นความรู้เท่าไม่ถึงการณ์เสียมาก โดยอยู่บนพื้นฐานของความคุ้นเคยกับระบบที่เป็น proprietary และอีกส่วนหนึ่งก็มาจากระบบประเมินผลของหน่วยงาน

• ความคิดแบบ proprietary ซึ่งในระบบนั้น เจ้าของผลงานสงวนสิทธิ์ทุกอย่างในการใช้งาน ดัดแปลง และเผยแพร่ พอจะเข้าร่วมวัฒนธรรมเสรี และอยากจะปล่อยผลงานของตัวเองบ้าง ก็ยังไม่แน่ใจนักว่าตนจะสูญเสียอะไรไปบ้าง ก็เลยเป็นที่มาของอาการกั๊กต่าง ๆ เช่น ให้ขออนุญาต ให้แจ้งเป็นลายลักษณ์อักษร ห้ามใช้ในงานเชิงพาณิชย์ ห้ามโน่นห้ามนี่ เรื่องนี้แม้แต่หน่วยงานของรัฐก็ยังคิด ซึ่งทำให้ผมประหลาดใจพอสมควร
• ระบบประเมินผลของหน่วยงาน ต้องการจะทราบว่า งบประมาณที่ได้ลงไปนั้น คุ้มค่าแค่ไหน มีใครนำไปใช้กี่มากน้อย ระเบียบวิธีต่าง ๆ ที่ต้องการ ตัวเลข จึงมาบังคับให้ผู้ปฏิบัติงานต้องหาวิธีนับที่ง่าย เช่น การลงทะเบียน การนับจำนวนการดาวน์โหลด การให้แจ้งหรือขออนุญาต รวมทั้งควบคุมวิธีเผยแพร่ เพื่อให้นับตัวเลขได้ครบถ้วนยิ่งขึ้น

ผมพบว่าสองเรื่องนี้เป็นปัญหาในทางปฏิบัติที่พบบ่อย นอกจากนี้ ยังมีเหตุผลบางแบบอาจจะคาบเกี่ยวกับแนวคิดทั้งสองแบบ เช่น การมีวาระซ่อนเร้นในการใช้ซอฟต์แวร์เสรีสร้างเครือข่ายสมาชิกอะไรบางอย่าง แต่วิธีการนั้นได้ไปจำกัดสิทธิ์การ redistribute เสีย ก็เลยกลายเป็นการใช้ประโยชน์จากกระแสซอฟต์แวร์เสรีและโอเพนซอร์สในทางที่ผิดไป

ลองมาดูทีละข้อ

ความคิดแบบ proprietary นั้น ตามความคิดของผมแล้ว ควรจะค่อย ๆ จางลงไปเองเมื่อบุคคลมีประสบการณ์มากขึ้นกับวัฒนธรรมเสรี ผู้ที่ได้เข้าร่วมในระดับลึก น่าจะรู้สึกทึ่งในปริมาณของซอฟต์แวร์เสรีที่คนทั้งโลกได้แบ่งปันกันจนกองพะเนินเทินทึกขนาดนี้ คุณจะพบว่า โค้ดที่คุณได้ปล่อยออกไปนั้น มันไม่ได้ยิ่งใหญ่อะไรนักเลย เป็นแค่น้ำหยดหนึ่งในทะเลเท่านั้น (แต่ก็ไม่ใช่ว่าไม่ยิ่งใหญ่แล้วจะไม่ให้ สิ่งที่คุณให้นั้น มีความสำคัญสำหรับผู้ใช้ของคุณเสมอ) สิ่งที่คุณ รับ นั้น มหาศาลกว่าสิ่งที่คุณ ให้ มากนัก เมื่อได้เห็นว่าชาวบ้านได้ร่วมแรงกันสร้างบ้านแปลงเมืองให้อยู่อาศัยกันมาขนาดนี้ คนที่มีสำนึกดีย่อมไม่รู้สึกเสียดายที่จะช่วยอะไรเล็ก ๆ น้อย ๆ ตอบแทน ความรู้สึกว่าได้สูญเสียอะไรไป จึงไม่น่าจะเกิดขึ้นกับคนที่ได้เข้าร่วมในระดับลึก

"ข้าพเจ้าได้เสรีภาพที่จะใช้ ดัดแปลง เผยแพร่ซอฟต์แวร์โดยไม่ต้องขออนุญาตมามากมาย ข้าพเจ้าก็ไม่เสียดายที่จะตอบแทนเช่นกันด้วยสิ่งที่ข้าพเจ้ามี"

ในทางกลับกัน หลักของ action-reaction ก็ยังใช้ได้ วัฒนธรรมเสรีเป็นวัฒนธรรมของการแบ่งปัน ยิ่งคุณให้ออกไปมากเท่าไร คุณก็ยิ่งมีโอกาสได้รับ contribution มากเท่านั้นด้วย ใครจะอยากไปช่วยรายงานบั๊กหรือส่งแพตช์ปรับปรุงให้กับซอฟต์แวร์ที่มีแนวโน้มจะกั๊กไว้หาผลประโยชน์เชิงพาณิชย์เล่า?

ถึงตรงนี้ ผมอยากสรุปว่า

ความคิดแบบ proprietary ละลายได้ด้วยวัฒนธรรมการมีส่วนร่วม

ปัจจัยที่ดูจะแก้ยาก คือเรื่องระบบประเมินผลของหน่วยงาน เป็นสิ่งที่เคยสร้างความเหนื่อยหน่ายต่อระบบให้กับผมมาแล้วเหมือนกัน แต่ผมอยากให้มองแนวคิดการประเมินโดยมาบังคับด้วย license นี้ ว่าเป็นปรากฏการณ์ที่อธิบายได้ดีด้วย หลักความไม่แน่นอนของไฮเซนแบร์ก คือยิ่งคุณพยายามจะวัดให้เที่ยงตรงมากเท่าไร คุณก็ยิ่งรบกวนระบบมากเท่านั้น ถ้าคุณไม่พยายามวัดให้ครบถ้วนด้วยการควบคุมการเผยแพร่ ตัวเลขที่แท้จริงที่คุณวัดไม่ได้นั้น ย่อมมากกว่าที่คุณวัดได้ด้วยการควบคุมแน่ ๆ คนที่ยอมแจ้ง ยอมลงทะเบียน เขาก็จะยังมาดาวน์โหลดไปใช้ ไปต่อยอดอยู่วันยังค่ำ แต่คนที่ไม่อยากแจ้ง ไม่อยากลงทะเบียนล่ะ? คุณได้สูญเสียคนกลุ่มใหญ่นี้ไปเพราะวิธีวัดของคุณเอง แถมยังสูญเสียคนที่จะช่วยเผยแพร่ปรับปรุงผลงานของคุณอีกหลายทอดเพราะการรวมศูนย์อีกด้วย

ประเด็นเรื่องการประเมินผลนี้ ดูจะแก้ยาก.. เพราะการเปลี่ยนระบบการคิดขององค์กรทั้งองค์กร ไม่ใช่เรื่องง่าย โดยเฉพาะถ้าองค์กรนั้น ๆ ยังมีงานทั้งแบบ proprietary และแบบเสรีปะปนกัน การแก้ปัญหาย่อมหลีกเลี่ยงการมีหลายมาตรฐานไม่ได้ แต่อย่างน้อย ๆ ผมก็อยากให้คำนึงถึงหลักความไม่แน่นอนไว้เสมอในการวัด ต้องหาวิธีวัดที่จะกระทบกับระบบให้น้อยที่สุด หรือมิฉะนั้น ก็ต้องยอมผ่อนคลายการวัดลง หรือปล่อยให้หน่วยงานอื่นที่ทำเรื่องการวัดโดยเฉพาะทำแทน

พอจะสรุปแบบนี้ได้ไหม?

แนวคิดการวัดผล ต้องคำนึงถึงผลกระทบต่อระบบ

กลับมาที่ประเด็นของ bact' ซึ่งค่อนข้างจะเสนอการเปลี่ยนแปลงทางสังคมแบบถอนรากถอนโคน ประเด็นของผมมีส่วนคาบเกี่ยวกับเขาบ้างพอสมควร แต่ผมไม่ค่อยเห็นด้วยกับการขยายขอบเขตไปถึงกับวิจารณ์ระบบโดยรวม ผมคิดว่ากลุ่มวัฒนธรรมเสรีของไทยยังไม่ได้มีอำนาจต่อรองมากพอสำหรับสิ่งที่ระบบจะต้องจ่ายเพื่อเปลี่ยนแปลง การวิจารณ์โดยผูกโยงกับวัฒนธรรมซอฟต์แวร์เสรี อาจทำให้ซอฟต์แวร์เสรีกลายเป็นสิ่งที่เทียบเท่ากับพวกหัวรุนแรงไป และจะทำให้ผู้คนบางส่วนต่อต้านโดยไม่จำเป็น ฉะนั้น ผมจึงยังจำกัดขอบเขตความเห็นของผมอยู่เฉพาะในแวดวงซอฟต์แวร์เท่านั้น

ผมมีข้อสังเกตเกี่ยวกับเรื่อง "ความเท่าเทียม" ที่ bact' พูดถึงในตอนท้าย ถ้าใครได้อ่านบทความ Homesteading the Noosphere (ฉบับแปล: ลงหลักปัญญาภูมิ) ก็จะพบข้อสังเกตที่น่าสนใจบางอย่าง คือในขณะที่วัฒนธรรมเสรีพูดถึง "ความเท่าเทียม" ระหว่างฝ่ายต่าง ๆ นั้น ก็ปรากฏว่ากลับมีการจัดระเบียบกันเองด้วยความเคารพซึ่งกันและกัน เอาเข้าจริงแล้ว วัฒนธรรมที่เสรีที่ดูเหมือนจะไร้ขอบเขตกลับมีเขตแดนที่เกิดแบบเป็นไปเอง เป็นความไม่เท่าเทียมที่เกิดจากความเท่าเทียม ในทางกลับกัน วัฒนธรรมของวงการซอฟต์แวร์ไทยยังไปไม่ถึงไหน ในยุคสงครามทะเล-ปลาดาวนั้น ถึงกับมีฝรั่งให้ความเห็นว่า "Forking is a norm in Thai culture." เป็นเพราะเรายังสลัดความคิดแบบ proprietary ออกไปไม่หมด ยิ่งเมื่อการ fork กลายเป็นเรื่องปกติ (เสรีแบบไทย ๆ) ก็เลยอาจจะส่งผลถึง license ที่คนคิดคอยจะลดเสรีภาพผู้ใช้ลงไปด้วย เพราะความระแวง

ในสังคมที่ mature นั้น ความเท่าเทียมได้สร้างความไม่เท่าเทียมที่สมเหตุสมผลตามหน้าที่ความรับผิดชอบ แต่สังคมที่ไม่ mature จะเรียกร้องความเท่าเทียมจนได้ความไม่เท่าเทียมแบบบังคับกลับมา

เอาเป็นว่า เรามาเริ่มสร้างความเท่าเทียมแบบ mature จากการสลัดความคิดแบบ proprietary ขณะเข้าร่วมวัฒนธรรมเสรีกันดีกว่า โดยไม่ลืมว่า เสรีภาพกับความรับผิดชอบเป็นของคู่กัน

Postcardware

จาก TODO list ที่บันทึกไว้ น่าจะถือได้ว่าเรื่อง libdatrie/libthai/swath เกือบเสร็จแล้ว เหลือออก libdatrie ตัวใหม่ที่ build บนระบบต่าง ๆ ได้ และอีกเรื่องที่เสร็จแล้วคือการ update Debian package ภาษาไทย ช่วงหลายวันที่ผ่านมาเลยมาทำเรื่องผลักดัน Thai Fonts Siampradesh (non-free) เข้า Debian

เริ่มจาก file ITP bug โดยระบุรายละเอียดของแพกเกจที่จะทำไว้ ซึ่งก็ปรากฏว่ามีความเห็นตอบมาอย่างรวดเร็วดังคาด ว่า license ของ ฟอนต์ประกวดของกรมทรัพย์สินทางปัญญาร่วมกับ SIPA นั้น ไม่ผ่านเกณฑ์ของ Debian Free Software Guidelines (DFSG) และไม่สามารถอยู่ในส่วน main ของ Debian ได้

รายละเอียดต่าง ๆ ผมเคย blog ไว้แล้ว โดยประเด็นที่ผมคิดว่าหนักหนาสาหัสที่สุดก็คือเงื่อนไขข้อ 2:

2. If you wish to adapt this Font Computer Program, you must notify copyright owners (DIP & SIPA) in writing.

ซึ่งเป็นหนึ่งในอาการที่พบบ่อยของคนที่ยังไม่คุ้นเคยกับ free culture จึงกำหนด license ออกมาแบบกั๊ก ๆ เพื่อให้ตนสามารถติดตามการดัดแปลงทั้งหมดได้ โดยขอให้ผู้ดัดแปลงเขียนจดหมายมาแจ้งเป็นลายลักษณ์อักษร แต่ปรากฏว่าเรื่องนี้กลายเป็นการจำกัดสิทธิ์ในการ redistribute ไป

license แบบนี้ เขาเรียกกันว่าเป็น Postcardware

บังเอิญจริง ๆ ที่ bact' เพิ่งพูดถึงเรื่องนี้เหมือนกันใน blog ของเขา:

สิ่งที่ผมคิดว่าน่าสนใจ และเป็นคุณสมบัติสำคัญของ open licenses ทั้งหลาย ไม่ว่าจะเป็น copyleft, GNU หรือ Creative Commons ก็คือ การไม่ต้องขออนุญาต ผมคิดว่าการไม่ต้องขออนุญาตนี้ทำให้ ข้อมูล โค้ด ไอเดีย ต่าง ๆ มันไหลเวียนได้อย่างอิสระ-ทันที ใครอยากจะเล่นอะไรก็เอา เต็มที่ ตามเงื่อนไขที่ประกาศไว้ชัดเจนล่วงหน้า ไม่ต้องรอไปรอมา ไม่ต้องตกอยู่ในภาวะไม่แน่ใจ

นี่ยังเป็นการพูดแบบนุ่มนวลมาก แต่ถ้าลองคิดถึงผลในทางปฏิบัติจริง ๆ มันอาจร้ายแรงกว่านั้น สำหรับกรณีของฟอนต์ DIP/SIPA นี้ การตั้งเงื่อนไขให้แจ้งเป็นลายลักษณ์อักษรมีปัญหาคือ:

• ในทางปฏิบัติ การแจ้งเป็นลายลักษณ์อักษรนั้น หากไม่มีคำตอบจากเจ้าของว่าได้รับแล้ว จะเกิดความไม่แน่นอนว่าจะสามารถเริ่มแก้ไขได้หรือไม่ เพราะถ้ามีการฟ้องร้องการละเมิด license ในภายหลัง จะเอาหลักฐานที่ไหนไปอ้างว่าได้แจ้งเป็นลายลักษณ์อักษรแล้ว ดังนั้น การต้องแจ้งเป็นลายลักษณ์อักษรจึงไม่ต่างอะไรกับการต้องขออนุญาตก่อนแก้ไข จึงไม่ถือว่าเป็น license ที่ free (เสรี) อย่างแท้จริง ไม่ว่าเงื่อนไขอื่น ๆ จะพร่ำบอกถึงเสรีภาพที่เปิดให้อย่างไรก็ตาม มันก็ยังเป็นเสรีภาพที่ต้องผ่านการขออนุมัติอยู่ดี
• license แบบนี้ ขาดความยั่งยืน จะเกิดอะไรขึ้นถ้าโครงการนี้ถูกปิดไปแล้วในแผนงานของหน่วยงานนั้น ๆ จดหมายที่แจ้งเป็นลายลักษณ์อักษรถึงหน่วยงานนั้น จำเป็นต้องผ่านการเซ็นรับรองของผู้บริหารหลายขั้นตอน แล้วถ้าคนที่รู้รายละเอียดของโครงการนี้ไม่อยู่แล้ว ไม่มีใครดูแลโครงการต่อ จดหมายนี้จะไปถูกดองเค็มไว้ที่ขั้นตอนไหนก็ไม่มีใครรู้ได้ การเปิดเสรีจึงเสมือนถูกปิดลงทันทีที่จบโครงการ แล้วถ้าวันดีคืนดี เกิดมีหน่วยงานใหม่มารับช่วงต่อ แล้วเกิดเปลี่ยนนโยบายไปเที่ยวฟ้องร้องคนที่แก้ไขไปแล้ว โดยไม่มีหลักฐานการตอบรับทราบมายืนยัน ก็ซวยสิ
• ใน รายการการทดสอบ license ของทีม debian-legal (มี สำเนาที่ Wikipedia) มีหลายกรณีที่แม้เป็นกรณีสมมุติ ก็มีนัยเชื่อมโยงกับโลกแห่งความเป็นจริง อย่างเช่น Desert Island test สมมุติว่ามีคนหิ้วซีดี Debian เข้าไปทำงานในชนบทห่างไกลที่ไม่มีอินเทอร์เน็ต แต่เขาต้องการพัฒนาซอฟต์แวร์ต่อเพื่อใช้ในชุมชนห่างไกลนั้น เขาไม่สามารถออกมาส่งอีเมล หรือแม้แต่ส่งจดหมายทางไปรษณีย์ได้ เขาไม่สามารถแจ้งเป็นลายลักษณ์อักษรได้ เขาก็หมดสิทธิ์แก้ไขซอฟต์แวร์เพื่อแบ่งปันผู้อื่นในชุมชนนั้นไปเลย

เมืองไทย ยังต้องทำความเข้าใจกับ free culture อีกมาก ไม่งั้น ก็จะมี license ที่ทำตาม ๆ กันมาแบบนี้อีกเป็นขบวน (เช่น ฟอนต์ของสหพันธ์อุตสาหกรรมการพิมพ์)

สำหรับ thaifonts-siampradesh นี้ แก้ไขโดยการขออนุญาตของ บริษัทเมตามีเดียเทคโนโลยี ครับ โดยผม subsidize งานส่วนนี้มาอีกที ใครที่จะแก้ไขต่อ ยังไม่มีความชัดเจนว่ายังต้องแจ้งให้กับ DIP-SIPA ทราบก่อนหรือไม่ เพราะแม้เจตนาของเงื่อนไขการแจ้งไม่น่าจะครอบคลุมถึงฟอนต์ที่ได้ดัดแปลงแล้วอย่าง thaifonts-siampradesh แต่เงื่อนไขข้อ 4 นั้นทำให้น่าเป็นห่วง:

4. The adapted version of Font Computer Program must be released under the term and condition of this license.

ซึ่งหมายความว่า ข้อ 2. จะยังคงบังคับใช้กับ thaifonts-siampradesh ไปด้วย ใครจะแก้ไขต่อ อย่าลืมแจ้ง DIP และ SIPA เป็นลายลักษณ์อักษรก่อนด้วย เพื่อความปลอดภัยของตัวท่านเอง

และทั้งหมดนี้ เป็นเหตุผลที่ thaifonts-siampradesh จำเป็นต้องเข้าไปอยู่ในหมวด non-free ของ Debian ไม่ใช่ main

IEEE Annals: Computers and the Thai Language

เมื่อช่วงกลางปีที่แล้ว ผู้ว่าจ้างบางคนของผมจะได้รับคำผัดผ่อนจากผม ด้วยเหตุผลสั้น ๆ ว่า "กำลังเขียน paper อยู่" แต่ไม่ได้ให้รายละเอียดอะไรเขามากนัก เพราะไม่ใช่สาระสำคัญสำหรับธุรกิจของเขา บัดนี้ paper นั้นได้ตีพิมพ์แล้วครับ:

Hugh Thaweesak Koanantakool, Theppitak Karoonboonyanan, Chai Wutiwiwatchai, "Computers and the Thai Language," IEEE Annals of the History of Computing, vol. 31, no. 1, pp. 46-61, Mar. 2009, doi:10.1109/MAHC.2009.5

เป็นเรื่องเกี่ยวกับความเป็นมาของระบบภาษาไทยในคอมพิวเตอร์ รู้สึกเป็นเกียรติที่ได้รับความไว้วางใจจากผู้ใหญ่ให้ร่วมเขียนบทความนี้

เป็นอีกครั้งหนึ่งที่รู้สึกว่า แม้จะมีการตรวจทานหลายรอบ แต่ยังคิดว่าน่าจะเขียนได้ดีกว่านี้ โดยเฉพาะถ้าตายังสู้แสงมอนิเตอร์ได้นานกว่านี้ แต่เวลาที่ใช้ไป ก็น่าจะพอเหมาะแล้ว ที่จะไม่ให้กระทบกับงานอื่นมากเกินไป

Songkran Updates

ความคืบหน้าต่าง ๆ ในช่วงสงกรานต์ที่ผ่านมา:

• แพตช์สำหรับ Xlib ที่เคยเขียนถึงใน blog เก่า ได้ check-in หมดแล้วที่ upstream ด้วยความช่วยเหลือของ Julien Cristau ผู้ดูแลแพกเกจ libx11 ของ Debian ตามที่เคย blog ไว้ ว่าเขาเสนอจะผลักดันเข้า upstream ให้ เป็นอีกครั้งหนึ่งที่ทำให้ชอบในสไตล์การทำงานของ Debian ที่พยายามทำงานร่วมกับ upstream ให้มากที่สุด สไตล์นี้มีให้พบเห็นที่ Ubuntu บ้าง แต่น้อยครั้ง ส่วนใหญ่จะรับแพตช์เร็ว แต่ไม่ค่อยช่วยผลักดันเข้า upstream แต่ก็ถือว่าเป็นประโยชน์ในแง่ที่ทำให้ผู้ใช้ได้ช่วยทดสอบเร็วขึ้น
• ในระหว่างนั้น พบว่า xchat-gnome พัง เรียกไม่ขึ้น โดยมีสาเหตุมาจากคำแปลไทย ก็เลยแก้และ commit เข้า SVN พร้อมได้รายงาน Debian #523739 เอาไว้ด้วย ใครเจอปัญหานี้ก็ไปดูได้ครับ หรือรอรุ่น 0.26.1 ซึ่งรวมรายการแก้นี้แล้วก็ได้
• ตาม แผนการ migrate libthai ใน Debian ตอนนี้ค่อนข้างเสร็จสมบูรณ์แล้วใน unstable รวมทั้ง binNMU ต่าง ๆ ที่ทำให้ตอนนี้ libdatrie0 ไม่มี reverse dependency เหลืออยู่อีกแล้ว ที่เหลือก็รอให้ผ่านเข้า testing ก่อนที่จะปรับแก้ระบบ build ของ libdatrie ต่อไป
• swath 0.4.0 ก็เข้าสู่ unstable แล้วเช่นกัน
• จากที่ได้รับรายงานเรื่องปัญหาการ build libdatrie ในระบบต่าง ๆ เช่น Mac, MinGW หรือแม้แต่ Linux distro ด้วยกันที่ไม่ใช่ Debian อย่าง Fedora ก็ได้ทยอยแก้ไปทีละเรื่อง โดยได้รับข้อมูลเบื้องต้นเกี่ยวกับ Mac จากคุณ bact' ผ่าน twitter และได้รับความช่วยเหลือจากคุณ cwt เกี่ยวกับ Fedora และ Mac ทางห้อง #tlwg, คุณ kengggg เกี่ยวกับ Mac ผ่านเมลลิงลิสต์ thai-linux-foss-devel, คุณ Beamer User และคุณ Sudchai เกี่ยวกับ cygwin และ MinGW ผ่านความเห็นใน blog ตอนนี้น่าจะถือได้ว่าตัว libdatrie เองผ่านในทุกระบบแล้ว ต่อไปก็เหลือตรวจสอบการ build แพกเกจที่ใช้ libdatrie คือ libthai และ swath ในแพลตฟอร์มต่าง ๆ ว่ายังมีปัญหาต้องแก้อีกไหม ก่อนที่จะออก libdatrie ตัวใหม่ต่อไป

นอกจากความคืบหน้าดังกล่าว ก็ปรากฏว่าพบปัญหาเล็กน้อยเกี่ยวกับการ migrate libthai ใน Debian โดยแม้จะมีการ upload libthai ที่ตัด link flag รอไว้แล้วใน unstable ตามที่อธิบายไว้ใน blog ก่อน ก็ปรากฏว่า pango ยังคงลิงก์ตรงกับ libdatrie0 อยู่ดี

ตรงนี้ตัวการยังคงอยู่ที่ libthai.la เจ้าปัญหาตัวเดิม คือแม้ผมจะไปแก้ libthai.pc ให้ประกาศ require datrie แบบ private แล้ว และเมื่อสั่ง 'pkg-config --libs libthai' ดูก็ไม่พบ -ldatrie ในผลลัพธ์แล้วก็ตาม แต่สุดท้าย pango ที่ build ออกมาก็ยังคงลิงก์ตรงกับ libdatrie0 อยู่ดี ทั้งนี้เพราะการติดตั้ง libthai.la ทำให้ระบบ build ของ pango ซึ่งใช้ libtool มันไปเจอไฟล์นี้ แล้วก็ไปลากเอา -ldatrie ตามที่ระบุในไฟล์นี้มาให้อยู่ดี..

แม้อยากจะตัดไฟล์นี้ออกเสียก็ยังทำไม่ได้ในตอนนี้ ในเมื่อ kdelibs 3 ยังคงอยู่ใน Debian ก็เลยต้อง hack ด้วยการแอบลบข้อมูล dependency_libs ออก ซึ่งก็ทำให้ -ldatrie ถูกตัดออกไปจากการ build ของ pango ได้ โดยคาดว่าคงไม่กระทบกับการทำงานของ kdelibs 3

ปัญหานี้ไม่ซีเรียสกับผู้ใช้ เพราะ symbol versioning ได้ช่วยป้องกันการพังเพราะ symbol ชนกันไปแล้ว แต่ปรากฏว่ามีเรื่องที่คาดไม่ถึง คือได้สร้างปัญหาให้กับระบบ buildd ของ Debian อยู่ระยะหนึ่ง เพราะการที่ pango ยังคงลิงก์ตรงกับ libdatrie0 ในระหว่างที่ผมได้ update libdatrie เป็น libdatrie1 ซึ่งทำให้ libdatrie0 หายไปจาก archive นั้น การ build ที่ buildd ที่เกี่ยวข้องกับ pango มีอันเจ๊งไปหมด เพราะ buildd chroot ทั้งหลายไม่สามารถดาวน์โหลด pango มาติดตั้งได้เนื่องจากขาด dependency คือ libdatrie0 ไป ตรงนี้ผมไม่รู้ตัวจนกระทั่งได้ไปติดต่อขอ binNMU กับ release team เขาถึงได้เล่าให้ฟัง..

คราวหน้า แม้จะวางแผนไว้ดียังไง ก็คงคิดเองเออเองแบบนี้ไม่ได้อีกแล้ว ควรจะรีบติดต่อทีมงานที่เกี่ยวข้องให้เร็วที่สุดเท่าที่จะเป็นไปได้

และอีกเรื่องหนึ่งคือ.. รอให้ KDE 3 obsolete ใน Debian เร็ว ๆ จะได้ปลดเปลื้องภาระความปวดหัวกับ libthai.la นี่เสียที

Mob Poetry

จาก tweet ของผมที่พรั่งพรูออกมาหลังฟังข่าวมาทั้งวัน (เพื่อความสะดวกในการอ้าง):

๏ ไม่มีสาระใดในโลกหล้า
พวกม็อบผลัดกันมาทำอดสู
ไม่มีใครล้ำเลิศน่าเชิดชู
ประชาชนโดนตู่นิรันดร์ไป
๏ เมื่อบ้านเมืองวุ่นวายไม่จบสิ้น
ประชาชนด่าวดิ้นไปยกใหญ่
เมื่อแสงทองส่องหล้านภาลัย
พบแต่ซากประดับไว้ในแผ่นดิน ฯ

Xlib updates

ความคืบหน้าอีกอย่าง คือเรื่องของภาษาไทยใน Xlib ที่ได้เคย รายงานไว้ เมื่อคืนนี้ debian มีการปรับรุ่น libx11 จาก 1.2 เป็น 1.2.1 โดยได้รับแพตช์หนึ่งในสี่ที่ได้เสนอไว้ใน Debian #520509 ส่วนอีกสามแพตช์นั้น เขารับว่าจะช่วยผลักดันเข้า upstream ให้ เย้! โดยบอกให้ผมปรับรูปแบบของแพตช์ให้เป็นไปตาม Guidelines ของ X.Org ก่อน

ทำไมตอนนั้นถึงหาหน้านี้ไม่เจอนะ.. สับสนกับกระบวนการของ X.Org เหมือนกัน เดี๋ยวต้องดูที่ x.org เดี๋ยวต้องไปที่ freedesktop.org วุ่นวายพิลึก ถ้าไม่นับช่องทางการส่งแพตช์ว่ามีทั้ง bugzilla และ mailing list อีก เคยเจอแนวนี้กับ evolution ก็เซ็งสุด ๆ ยิ่งถ้าเป็นโครงการที่เกี่ยวกับ mono แล้ว ยังต้องไปดูที่ novell.com อีกจุดหนึ่งด้วย ไม่ชอบโครงการสไตล์นี้เลย แบบ GNOME นี่แหละชัวร์ดี bugzilla ที่เดียวเลย ใครสะเออะไปคุยใน mail ก็โดนไล่มา bugzilla หมด แบบนี้สิ ค่อย contribute ง่ายหน่อย

อย่างไรก็ดี บ่นกับตัวเองเสร็จแล้วก็ไปปรับแพตช์ตามที่เขาแนะ แล้วก็ตอบเขากลับไป (ไม่ว่าอะไรคร้าบ ขอบคุณอย่างสูงที่เสนอจะช่วยผลักดันแพตช์ให้) พร้อมกันนี้ ก็เอาแพตช์ใหม่มา build deb แล้ว upload เข้า debclub "ก้านกล้วย" เสียเลย update กันได้ครับผม เพื่อการใช้งานภาษาไทยที่ราบรื่น

swath 0.4.0 in experimental

ต่อจาก blog ที่แล้ว ตอนนี้ swath 0.4.0 ก็เข้าไปอยู่ใน Debian experimental เรียบร้อยแล้วเช่นกัน

swath รุ่นนี้ นอกจากการเปลี่ยนมาใช้ libdatrie 0.2 ก็มีการเปลี่ยนแปลงย่อย ๆ ตามปกติ โดยคราวนี้ได้ทรมาน swath ด้วย valgrind คล้ายกับที่ เคยทำกับ libthai เพียงแต่ไม่ได้ล้วงลึกลงไปแก้อะไรมากนัก เนื่องจาก swath ไม่ใช่โค้ดของผมเอง (แต่เป็นของ คุณไพศาล ทำไว้) ยังไม่มั่นใจพอที่จะแก้อะไรใหญ่โต

แต่ก็โชคดีที่สิ่งผิดปกติที่ valgrind ตรวจพบ ไม่ได้แก้ยากเกินไป โดยที่ได้แก้ไปก็ได้แก่:

• หน่วยความจำรั่ว 1 จุด
• การใช้ new[] กับ delete[] ที่ไม่เข้าคู่กัน
• การใช้ strcpy() กับสตริงที่ซ้อนทับกัน
• การ branch โดยอาศัยค่าที่ไม่ได้กำหนดค่าเริ่มต้นไว้

มีรายการสุดท้ายที่ผมยังไม่มั่นใจพอที่จะแก้หนึ่งรายการ เนื่องจากทำให้ผลลัพธ์การตัดคำเปลี่ยนไป เลยทิ้งไว้ก่อน เป็นเรื่องของการ branch โดยอาศัยค่าที่ไม่ได้กำหนดค่าเริ่มต้นไว้

เป็นอันว่า เราได้ swath ที่สามารถปรับพจนานุกรมได้ละ ไว้เดี๋ยวรอย้าย libdatrie1 จาก experimental เข้า unstable ก่อน แล้วจึงย้าย swath ตามมา ระหว่างนี้ ใครสนใจทดสอบก็ลองได้จาก experimental ครับผม

libthai 0.1.11 ready in experimental

ตาม แผนการ migrate libthai ที่ได้วางไว้ ตอนนี้มีความคืบหน้าเล็กน้อย

หลังจากที่ได้เตรียม libdatrie 0.1.4 ใน debian unstable ไว้แล้ว ก็ออก libdatrie 0.2.1 และ libthai 0.1.11 ตามมา พร้อมกับ upload แพกเกจทั้งสองเข้าใน debian experimental เรียบร้อย โดยการ upload ทั้งหมด ก็เป็นการเพิ่ม symbol versioning ทั้งใน libdatrie0 และ libdatrie1 ก็เป็นอันว่าสามารถปรับรุ่น libthai จาก unstable เป็นรุ่นใน experimental ได้โดยไม่มีปัญหาโปรแกรมพังอีกต่อไป

ต่อไปก็รอ libdatrie 0.1.4 ย้ายเข้า testing (เพื่อเตรียมการปรับรุ่นสำหรับผู้ใช้ testing ด้วย) ซึ่งเหลือเวลาอีก 4 วันสำหรับรอรายงานบั๊กใน unstable ถ้าไม่มีอะไรผิดพลาดก็คงได้เข้า testing ในวันที่ 11-12 เม.ย. จากนั้นจึงเริ่มย้ายแพกเกจใน experimental เข้า unstable ได้

ก่อนหน้านี้ ผมได้ upload scim-thai และ gtk-im-libthai ซึ่ง build กับ libthai-dev 0.1.9-5 ใน unstable ไปแล้ว ซึ่งเป็นการตัดการลิงก์ตรงกับ libdatrie0 ออก โดยพร้อมกันนี้ก็ถือโอกาสตัดการลิงก์ตรงกับไลบรารีอื่นที่ไม่จำเป็นที่ GTK+ ไปดึงมาให้ด้วย เช่น libatk, libfreetype, libcairo ฯลฯ ทำให้ dependency ลดลงไปเยอะ แต่การตัดการลิงก์ตรงกับ libdatrie0 ก็เป็นการลดความเสี่ยงต่อการพังลงทางหนึ่ง แต่ทั้งนี้ทั้งนั้น pango language engine ภาษาไทย รวมทั้ง libm17n-0 ยังคงลิงก์ตรงกับ libdatrie0 อยู่ ดังนั้น libdatrie0 0.1.4 ที่มาช่วยแยกรุ่นของ symbol ก็ยังคงจำเป็น

ในระหว่างนี้ ถ้าใครอยากช่วยทดสอบ libthai ใน experimental ก็สามารถเริ่มทำได้นะครับ ตอนนี้ไม่ทำโปรแกรมพังแล้ว ผมเองก็กำลังใช้อยู่ เพื่อทดสอบการใช้งาน หรือจะรอใช้ใน unstable หรือ testing เพื่อความปลอดภัย ก็ไม่มีปัญหาครับ ส่วนผู้ใช้ Ubuntu ก็คงรอใช้ใน karmic ได้หลังจากนั้น

สาเหตุสำคัญที่ต้องมีการปรับ libdatrie ครั้งนี้ ก็เพื่อขยายขีดจำกัดของพจนานุกรมที่ใช้ในการตัดคำ ทำให้ตอนนี้สามารถเพิ่มคำเข้าในพจนานุกรมได้อย่างอิสระแล้ว ความจริงในอนาคตผมอยากให้ช่วยกันเสนอคำเข้ามา เพื่อทำให้ libthai ตัดคำได้ครอบคลุมยิ่งขึ้น แต่ก็ยังขี้เกียจทำ interface ตอนนี้ก็อาจจะใช้ช่องทางอย่างอีเมลหรืออื่น ๆ ไปก่อน จนกว่าจะติดตั้งระบบติดตามบั๊กเสร็จ

อีกโปรแกรมหนึ่งที่กำลังจะได้อานิสงส์จาก libdatrie ตัวใหม่ ก็คือ swath ซึ่งใน SVN ได้ปรับมาใช้ libdatrie ตัวใหม่แล้ว ทำให้สามารถปรับพจนานุกรมสำหรับตัดคำได้ ตอนนี้กำลังอยู่ระหว่างเก็บกวาดโค้ดเพื่อเตรียมออกรุ่นใหม่

libthai/libdatrie Migration in Debian

ระหว่างนี้ยังคงอยู่ในช่วงเคลียร์ TODO list ต่อไป โดยหลังจาก file bug เกี่ยวกับ X locale และ Pango ไปแล้ว ก็มาที่เรื่องของ libthai ซึ่งต้องทำหลายขั้นตอน ระหว่างที่ต้องหยุดรอกระบวนการ ก็สลับไปหยิบเรื่องการ update แพกเกจภาษาไทยใน Debian มาทำไปพลาง ๆ แล้วก็แวะมาที่เรื่อง ฟอนต์ นิดหน่อย ส่วนเรื่องบั๊กความกว้างของตัวเลขอารบิกในฟอนต์ที่ว่าจะทำนั้น ดูแล้ว เป็นปัญหาเกี่ยวกับ hinting ซึ่งจะกินเวลานานเกินไป เลยข้ามไปก่อน เมื่อรายการที่รอผ่านแล้ว ก็เลยกลับมาดูเรื่อง libthai ต่อ

เรื่องของ libthai ก็เริ่มจากการ ออก libdatrie 0.2.0 ที่ ทำค้างไว้ และก่อนที่จะออก libthai ตามมา ก็ upload libdatrie เข้า Debian experimental ก่อน เพื่อทดสอบความเรียบร้อยให้แน่ใจ แต่เนื่องจากรุ่นนี้มีการเปลี่ยน SONAME ของไลบรารี จาก libdatrie.so.0 เป็น libdatrie.so.1 ทำให้มีแพกเกจไบนารีตัวใหม่ คือ libdatrie1 และอื่น ๆ ก็เลยต้องไปผ่านการตรวจสอบใน NEW queue ของ Debian ก่อน เลยเป็นช่วงให้หยุดรอไปทำอย่างอื่นไปพลางอย่างที่ว่าไป

เมื่อผ่านแล้ว ก็มา ออก libthai 0.1.10 ที่ใช้ libdatrie ตัวใหม่ แล้วอัปโหลดเข้า Debian experimental ตามเข้าไป ซึ่งปรากฏว่าเจอตอเข้าให้ เกี่ยวกับเรื่องการ upgrade ไลบรารีข้ามรุ่น SONAME ใครที่เคยอ่านพบใน Debian New Maintainer's Guide แล้วไม่เข้าใจ ว่าทำไมเขาแนะนำ new maintainer ว่าไม่ควรเริ่มจากแพกเกจที่เป็นไลบรารี ก็ขอให้เชื่อเถอะ ว่าเป็นคำแนะนำที่ควรแก่การรับฟังอย่างยิ่ง

ถ้าผมสาธยายรายละเอียดปลีกย่อยเกี่ยวกับไลบรารีที่พบมาทั้งหมด blog ก็คงจะยาวจนไม่ได้เขียนบันทึกที่ตั้งใจจะเขียน ก็ขอข้ามมาที่ปัญหาที่พบในครั้งนี้เลยละกัน

ปัญหาที่พบในครั้งนี้ พอสรุปได้ 2 ประเด็นใหญ่ ๆ

1. ปัญหาการจัดการการเปลี่ยนแปลง ABI ที่ไม่เข้ากับของเดิม
2. ปัญหาของ transitive dependency

อาการเป็นดังนี้:

• client ที่ลิงก์กับ libthai (เช่น Thai language engine ใน Pango) ไปลิงก์กับ libdatrie ไว้ด้วย ผ่านค่า "-lthai -ldatrie" ใน pkg-config ดังนั้น language engine นั้นจึงลิงก์กับ libdatrie 2 ชุด ลิงก์โดยตรงขณะคอมไพล์ชุดหนึ่ง และลิงก์ผ่าน libthai อีกชุดหนึ่ง
• เมื่อ libthai มีการปรับรุ่น โดยรุ่นใหม่ไปลิงก์กับ libdatrie1 ในขณะที่ client ยังคงลิงก์กับ libdatrie0 อยู่ เมื่อโหลดขึ้นมาทำงาน จึงกลายเป็นโหลด libdatrie ขึ้นมา 2 รุ่นพร้อมกัน คือ libdatrie0 และ libdatrie1
• เนื่องจากมีการเปลี่ยนแปลง ABI ที่ไม่เข้ากับของเดิม โดยที่ไม่ได้จัดการเรื่อง symbol ให้ดี ไลบรารีทั้งสองชุดจึงมี symbol ซ้ำกัน แต่ทำงานไม่เหมือนกัน จะเรียกได้ตัวเก่าหรือตัวใหม่ก็สุดแท้แต่ linker จะบังเอิญไปหยิบตัวไหนมาให้
• ผลคือ โปรแกรมทำงานเพี้ยน หรือบางครั้งก็ segfault ไปเลย

ปัญหานี้ ถ้าสามารถโละทุกอย่างที่เกี่ยวข้องทิ้งแล้วคอมไพล์ใหม่หมดจาก libdatrie ตัวใหม่ ก็จะแก้ปัญหาได้ แต่คุณก็รู้ ว่ามันเป็นไปได้ยากสำหรับ distro ขนาดใหญ่อย่าง Debian โดยเฉพาะเมื่อการเปลี่ยนแปลงมาจากแพกเกจเล็ก ๆ ที่มีผลแค่กับภาษาไทยภาษาเดียว (หรือแม้แต่ถ้าคุณคอมไพล์ทุกอย่างจากซอร์สเอง การคอมไพล์ระบบใหม่หมดก็ไม่ใช่เรื่องสนุก) ดังนั้น การจัดการการปรับรุ่นของไลบรารีจึงมีความละเอียดอ่อนค่อนข้างมาก

ได้สรุปไปแล้วข้างต้น ว่าปัญหามีสองประเด็นหลัก ขอเล่าประเด็นหลังก่อน

Transitive Dependency เป็นปัญหาที่ไม่น่าจะเกิด สำหรับโปรแกรมที่ลิงก์กับ shared library ไม่ใช่ลิงก์แบบ static กล่าวคือ ถ้า client ของ libthai ไม่ได้เรียกใช้อะไรใน libdatrie เลย ก็ไม่ควรต้องลิงก์กับ libdatrie โดยตรง ปล่อยให้ libthai ลิงก์ไปคนเดียวก็พอแล้ว จากนั้น เมื่อมีการปรับรุ่น libthai ก็จะไม่กระทบกับ libdatrie อีก

เรื่องนี้เป็นความบกพร่องของผมเองที่ไม่ระวังเรื่อง link flag ของ libthai โดยแม้จะพยายามหลีกเลี่ยง libtool มาใช้ pkg-config แล้ว ก็ยังคงติดแฟล็ก '-ldatrie' มาในแฟ้ม pkg-config ของ libthai อยู่ กล่าวคือ ถ้าเป็นลิงก์โปรแกรมผ่าน *.la ที่สร้างโดย libtool นั้น มันจะไปดึงเอา dependency ของไลบรารีมาลิงก์ตรงหมด (เป็นสาเหตุหนึ่งที่ Debian และดิสโทรอื่นบางดิสโทรพยายามจะกำจัดแฟ้ม *.la ออกจากระบบให้หมด แต่ของ libthai ยังต้องคงไว้ เพื่อให้ kdelibs 3.x ใช้โดยเฉพาะ แต่ก็ไม่ได้มีผลอะไรกับระบบการลิงก์ เพราะ libthai ใช้ pkg-config เป็นหลัก) ในขณะที่การใช้ pkg-config จะสามารถแยก dependency ที่เป็น private ออกจาก public ได้ แต่พอมาใช้ pkg-config แล้ว ผมก็ยังเข้าใจผิดว่าการลิงก์นั้นยังต้องใช้ link flag เหมือน libtool ซึ่งไม่จำเป็นเลย

ดังนั้น ถ้าก่อนหน้านี้ ผมประกาศให้ libdatrie เป็นรายการ requires แบบ private ในแฟ้ม libthai.pc ก็จะไม่เกิดการลิงก์ client กับ libdatrie โดยตรงเป็นจุดที่สอง นอกเหนือจากผ่าน libthai และปัญหา ABI นี้ก็จะไม่เกิดขึ้นเลย

ปัญหานี้ Loic Minier ซึ่งเคยเป็น sponsor ให้กับแพกเกจ libthai ของผมได้ชี้ให้เห็น เขาไม่ได้พูดละเอียดขนาดนี้หรอก ผมเรียบเรียงและอธิบายเพิ่มเติมเพื่อให้เข้าใจง่ายเข้าน่ะ

แต่ผมกลับไปแก้ไขอดีตไม่ได้ ได้แต่กำจัด flag นั้นเพื่อลดรายการ dependency และการโหลดไลบรารีลงในอนาคต แล้วก็มาแก้ปัญหา ABI ที่พบอยู่ตรงหน้านี้

Incompatible ABI Change จาก libdatrie0 เป็น libdatrie1 มีการเปลี่ยนแปลง API โดยมีชื่อฟังก์ชันซ้ำกับของเดิมบางส่วน ดังนั้น เมื่อถูกโหลดขึ้นมาพร้อมกันโดยไม่มีการจัดการแยกแยะ symbol แบบนี้ loader จึง resolve symbol มั่ว แต่ปัญหานี้สามารถเลี่ยงได้ ด้วยการทำ symbol versioning ซึ่งพูดง่าย ๆ ก็เป็นเหมือนการใส่ namespace ให้กับแต่ละ symbol นั่นเอง โดยแยกแยะ ABI เป็นรุ่น ๆ ทับซ้อนกันได้ วิธีนี้มีข้อแม้ว่าไลบรารีจะต้องลิงก์ตรงกับ client เท่านั้น จะไม่มีผลต่อการโหลดผ่าน dlopen เพราะข้อมูล version ในการเรียก จะรู้ได้ในขณะลิงก์เท่านั้น ส่วนถ้าผ่าน dlopen การเรียกก็จะไม่มีการระบุ version

แต่กรณีของเรา libthai ก็ลิงก์ตรงกับ libdatrie อยู่แล้ว สามารถนำมาใช้แก้ปัญหาได้ โดยผมต้องกลับไปใส่ symbol version ใน libdatrie ตัวเก่า แล้ว ออก libdatrie 0.1.4 เพื่อ upload เข้า unstable รอไว้ก่อน พร้อมกันนั้นก็ใส่ symbol version ให้กับ libdatrie ใน experimental ไว้ด้วย เมื่อ libthai ตัวใหม่ย้ายจาก experimental เข้า unstable จึงจะไม่เกิดปัญหาชื่อชนกัน ซึ่งกว่าผมจะย้ายมาได้ ก็ต้องรอให้ libdatrie 0.1.4 ย้ายเข้าไปถึง testing เสียก่อน (ใช้เวลาประมาณ 10 วัน) เพื่อให้ผู้ใช้ testing สามารถ upgrade ได้โดยไม่สะดุดเหมือนกัน

เรื่องการทำ symbol versioning นี้ Josselin Mouette เป็นคนชี้ให้เห็น แต่ความรู้พื้นฐานเกี่ยวกับ symbol versioning ที่ทำให้เข้าใจในสิ่งที่เขาบอก ก็ต้องขอบคุณ Martin Wuertele ซึ่งเป็น Application Manager ในกระบวนการสมัครเป็น Debian Developer ของผม เพราะข้อสอบภาคทฤษฎีของเขา ทำให้ผมไปค้นคว้าจนได้ความรู้ประดับสมองรอไว้ ตอนนี้ก็ได้เวลางัดออกมาใช้ในภาคสนามละ

จากเงื่อนไขต่าง ๆ ที่เล่ามา แผนการโดยสรุปของผมจึงเป็นขั้น ๆ ดังนี้:

1. update libthai ใน unstable (0.1.9-5) เพื่อตัด link flag '-ldatrie' ออก รอไว้ ในระหว่างนี้ ถ้าแพกเกจไหนที่ลิงก์กับ libthai มีการ build เกิดขึ้น ก็จะตัดลิงก์ตรงกับ libdatrie0 ออกไป เลี่ยงปัญหาการพังไปโสดหนึ่ง หรืออย่างน้อยก็ตัดการโหลดไลบรารีที่ไม่จำเป็นออกไปหนึ่งรายการ แต่ถ้ายังมีใครไม่ build ก็ไม่เป็นไร ยังมีก๊อกสอง
2. update libdatrie0 ใน unstable (0.1.4-1) ซึ่งเพิ่ม symbol version รอไว้ เพื่อที่เมื่อ libthai ตัวใหม่ย้ายเข้า unstable แล้ว จะไม่เกิดการชนของ symbol และต้องรอให้แพกเกจนี้ย้ายเข้าไปถึง testing เสียก่อนด้วย จึงจะดำเนินการขั้นต่อไปได้
3. ออก libdatrie1 ตัวใหม่ที่มี symbol version และ upload เข้า experimental
4. update libthai ใน experimental อีกครั้ง โดยลิงก์กับ libdatrie1 ที่มี symbol version พร้อมกับตัด link flag เหมือนที่ทำใน unstable ด้วย นอกจากนี้ จากที่ Josselin ได้ท้วงว่าอาจมีปัญหากับการ upgrade เพียงบางส่วนจาก lenny ที่ยังใช้ libdatrie0 ตัวเก่า จึงควรเพิ่ม versioned conflict กับ libdatrie0 (<< 0.1.4) ด้วย
5. เมื่อถึงเวลาอันควร (ซึ่ง Josselin บอกว่า น่าจะเป็นหลัง GNOME 2.26 migration ล็อตใหญ่ที่กำลังจะเริ่ม) ก็ติดต่อกับ release team เพื่อย้าย libthai เข้า unstable โดยขอ binNMU สำหรับทุกแพกเกจที่ลิงก์กับ libthai ซึ่งน่าจะทำให้ libdatrie0 รุ่นเก่าถูกปลดระวางไปอย่างสมบูรณ์

สำหรับ swath ตัวใหม่ที่ลิงก์กับ libdatrie1 แล้วนั้น คงจะออกเมื่อ libdatrie1 ตัวใหม่อยู่ตัวแล้ว อาจจะระหว่างอยู่ใน experimental หรือหลังจากย้ายเข้า unstable ก็แล้วแต่ความเหมาะสม