Intro to Debian Process (ตอนจบ)

ตอนก่อน:

• ตอนที่ 1
• ตอนที่ 2
• ตอนที่ 3

เอาละ พูดถึงกระบวนการทั่วไปมาแล้ว ถ้าคุณสนใจจะ build debian package สำหรับซอฟต์แวร์โปรดของคุณ ก็อาจจะเริ่มจากฝึก build จาก New Maintainers' Guide แต่ถ้าคุณ build คล่องถึงระดับหนึ่งแล้ว การจะเริ่มอัปโหลดแพกเกจเข้า debian จะมีประเด็นต่างๆ ที่จะถูกตรวจสอบเยอะแยะ เพื่อให้เป็นไปตาม Debian Policy เครื่องมือหลักที่จะช่วยคุณได้ก็คือ lintian และ linda ซึ่งเป็นเครื่องมือตรวจสอบความถูกต้องของ debian package คล้ายๆ กับ lint สำหรับโปรแกรมภาษา C น่ะแหละ

ต่อไปนี้เป็นประเด็นที่พบบ่อย พึงระวังขณะสร้าง debian package:

• CVS directories ควรลบไดเรกทอรี CVS ทั้งหลายที่ยังตกค้างอยู่ โดยเฉพาะถ้าคุณ maintain debian script ใน CVS เรื่องนี้เป็นเรื่องที่พบบ่อยมาก ถ้าไม่อยากถูกตรวจพบด้วยข้อหาตื้นๆ ก็ควรเตือนตัวเองเสมอๆ ให้ลบ CVS ก่อน build ซึ่งหมายความว่า คุณไม่ควร build debian package ภายใน CVS working copy แต่ควรคัดลอกออกมา build ข้างนอก จะสะดวกกว่า
• native/non-native ถ้าแพกเกจที่คุณ build มี upstream source ไม่ใช่เป็นแพกเกจเฉพาะใช้ใน debian ก็ควรจะ build เป็นแบบ non-native โดยใช้ upstream tarball ที่เปลี่ยนนามสกุลจาก .tar.gz เป็น .orig.tar.gz และ ห้ามแตะต้อง ข้อมูลใดๆ ใน upstream tarball ปล่อยให้เป็น pristine source ไว้ แล้ว dpkg-buildpackage จะสร้าง .diff.gz เพื่อใช้เพิ่ม debian script ให้ ถ้ามันไม่ gen แบบนี้ให้ ก็ควรตรวจสอบ ว่าคุณได้เปลี่ยนชื่อ upstream tarball (หรือทำ symlink ในอีกชื่อ) ก่อน build หรือไม่ มีเหตุผลดีๆ มากมายในการทำให้แน่ใจว่ามีการแยก .orig.tar.gz กับ .diff.gz เช่น ทุก release จะใช้ pristine source ร่วมกัน ต่างกันแค่ .diff.gz ที่ใช้เพิ่ม debian script ทำให้ประหยัดเนื้อที่และ bandwidth ในการ upload/download รวมทั้งสะดวกในการตรวจสอบความเปลี่ยนแปลงเทียบกับ upstream และระหว่าง release ต่างๆ เป็นต้น
• copyright เรื่องนี้จะถูกตรวจสอบเป็นเรื่องแรกๆ เลย คุณควรแน่ใจว่ากรอกข้อมูลเกี่ยวกับแหล่งต้นตอของ upstream source, ข้อมูลลิขสิทธิ์ของ upstream และไฟล์ต่างๆ ที่ใช้ประกอบการสร้าง debian package ต้องให้ครบ และที่สำคัญ อย่าลืมใส่ข้อความ disclaimer ที่มีมากับข้อความลิขสิทธิ์เสมอ และถ้าแพกเกจนั้นใช้ license ที่เป็นที่รู้จัก เช่น GPL, LGPL, BSD, Artistic ก็ไม่ต้องใส่ไฟล์ COPYING มา แต่เขียนข้อข้อความสั้นๆ ที่ท้าย disclaimer ว่าใน debian ให้อ่านข้อความเต็มของ license ดังกล่าวได้ที่ /usr/share/common-licenses/<license> มีการพูดถึงรายละเอียดเรื่องนี้ใน กระทู้ ใน debian-legal
• debhelper comment ชาว debian เขาค่อนข้างเนี้ยบกับแฟ้ม debian/rules ว่าควรจะสะอาด คุณอาจใช้ debhelper ช่วยสร้างสคริปต์ต่างๆ โดยอัตโนมัติ รวมทั้ง debian/rules นี้ด้วย แต่คำสั่ง dh_* ที่คุณไม่ใช้ คุณอาจเสียดายที่จะลบทิ้ง โดยใส่คอมเมนต์ไว้ ขอบอกว่าอย่าทำ ควรลบทิ้งไปเลย ถ้าไม่อยากถูก sponsor ตีมือ
• debian/rules พยายามให้ debian/rules สะอาดที่สุดเท่าที่จะทำได้ แฟ้มนี้โดยเนื้อหาก็คือ Makefile นั่นเอง แต่พยายามอย่าใช้ script เฉพาะกิจมากเกินไป เช่น สั่ง cp ตรงโน้น rm ตรงนี้ แต่ควรพยายามใช้คำสั่ง dh_* ของ debhelper ถ้าเป็นไปได้ ซึ่งถ้าตรวจสอบดีๆ จะพบว่ามีคำสั่งครอบคลุมหลายๆ งานที่ไม่คิดว่าจะมีใน distro อื่น (ทุกคำสั่งมี man page ให้อ่าน!) ซึ่งการใช้คำสั่งเหล่านี้ นอกจากจะง่ายแล้ว ยังมีผลดีตรงที่ไม่เสี่ยงต่อการละเมิด debian policy ด้วย โดยเฉพาะเวลามี transition ใหญ่ๆ ของระบบ (เช่น Xorg 7 ที่ผ่านมาหมาดๆ) จะเห็นประโยชน์ชัดมาก โดยแค่ build แพกเกจใหม่ด้วย debhelper ตัวใหม่ โดยแทบไม่ต้องแก้อะไรเลย ก็ transition ไปกับหมู่คณะได้แล้ว
• NMU ตรงนี้เป็นประเด็นปลีกย่อย สำหรับกรณีที่คุณ build package ของคนอื่น เพื่อแก้ปัญหาอะไรบางอย่าง พยายามทำตาม policy เรื่อง Non-maintainer upload กล่าวคือ ใช้เลข release แบบทศนิยม และระบุ * NMU หรือ * Non-Maintainer Upload ใน debian/changelog ด้วย

โดยส่วนใหญ่แล้ว หลายประเด็นสามารถถูกตรวจสอบได้ด้วย lintian/linda ดังนั้น คุณจะพบว่า สำหรับ debian แล้ว tool ตรวจสอบดังกล่าว ไม่ได้เป็นแค่เครื่องมือประกอบ แต่กลายเป็นส่วนหนึ่งของ build process เลยทีเดียว (ผมจึงใช้ debuild แทน dpkg-buildpackage และถ้าจะให้ดี ควรใช้ pbuilder สำหรับแพกเกจที่เสี่ยงต่อการลิงก์ไลบรารีผิดที่) ถึงจะเป็นแค่ warning ก็ไม่ควรเพิกเฉย

ฟู่.. ปาดเหงื่อหน่อย ในที่สุดก็เขียนจบ ขอขอบคุณที่ติดตามครับ ทั้งหมดนี้คงยังครอบคลุมไม่หมด แต่คงพอให้เห็นภาพของกระบวนการทั้งหมด ความละเอียดลออของ debian ทำให้ยังรักษาคุณภาพไว้ได้ แม้จะเป็นการทำงานร่วมกันของคนเรือนพันทั่วโลก มี package จำนวนมโหฬาร และ architecture ต่างๆ ให้ดูแลมากมาย เข้ามาในโลกของ debian แล้ว จะรู้สึกถึงการใช้คอมพิวเตอร์ให้เป็นประโยชน์มากมาย ความเป็นอัตโนมัติของ apt ยังเป็นแค่มุมมองสำหรับผู้ใช้เท่านั้น แต่สำหรับนักพัฒนา ก็จะพบความเป็นอัตโนมัติอีกหลายอย่าง เช่น build daemon ที่ช่วยการ port และ transition ต่างๆ โดยอัตโนมัติ หรือการเคลื่อนของแพกเกจจาก unstable มา tesing โดยอัตโนมัติ พร้อมกันนั้น ความเข้มแข็งของระเบียบปฏิบัติต่างๆ สำหรับมนุษย์ ก็ทำให้คนที่กระจายอยู่ในส่วนต่างๆ ของโลก สามารถทำงานร่วมกันได้อย่างแน่นแฟ้น