אני כן מסכים שהמנגנונים ליישום טלאים מרובים הם לא מספיק טובים. רוב החבילות שרוצות לשמור תיעוד של טלאים מרובים עושות בניה בשני שלבים, מה שאינו אידאלי.

לא הבנתי מה ניסית להגיד. מהם שני השלבים? האם שני שלבים אינה המטרה? מפתחים עשויים להתענין בהבדלים בין המקור "של ההפצה" לבין המקור "האמיתי" לעומת זאת הרוב לא יתענין בכך. קשה לקלוע לרצון של כולם.

למה בדיוק אתה מתכוון?

דווקא מנגנון dpatch נותן פתרון סביר ונוח כמעט כמו בניית rpm מהבחינה הזו. וגם מוסיף אפשרויות שחסרות ב־rpm לתחזוקת הטלאים.

לעומת זאת חסרה לי האפשרות להוסיף מקור בינארי (לא טקסטואלי) נוסף.

צפריר

dpatch לא פותר את הבעיה הבסיסית, והיא שהמנגנון הרגיל (dpkg-source) לא פותח לך את קוד המקור כפי שדביאן רואה אותו. dpatch בסה"כ אומר שחלק מתהליך הבניה גם מכניס את השינויים. חשוב. נחמד, אבל לא טבעי כמו הדבר הרגיל.

לגבי מקור בינארי נוסף, התשובה הדביאנית הרגילה היא "תייצר חבילה בשבילו ותעשה build-depends". לא אוהב אותה בעצמי.


לדוגמא: יש תוכנה בשם "rsyncrypto". בחלק מנסיונות השיפור, אני רציתי להוסיף לה תמיכה ב-make test. הוא מבצע סדרה של הצפנות ושחזורים ומשווה לערכים ידועים. הבעיה היא שלא הגיוני לשים את סדרת הערכים הידועים בתוך מקור נפרד.

הבעיה היא שאם אני מייצר חבילה שנקראת "rsyncrypto-regtest", הכי הגיוני מבחינת התקנה זה לעשות שהחבילה תהיה תלויה ב-rsyncrypto. מצד שני, אנחנו צריכים ש-rsyncrypto יהיה build-dep ב-rsyncrypto-regtest. במילים אחרות, אנחנו מייצרים פה תלות מעגלית.

שחר

גם בבניית rpm זה "לא אוטומטי" באותה המידה.

אתה יכול פשוט להריץ:

dpatch apply-all

ויש לך את המקור עם כל התיקונים.


אני בסה"כ מרוצה ממנו, חוץ מהעובדה שהוא עדיין לא משולב לפעמים מספיק טוב בכלי הבניה.

"כל משתמש יכול לבנות חבילות על מערכת דביאן, גם אם הוא לא root. "

גם ב-RPM משתמש יכול לבנות חבילות. ממתי צריך שהוא יהיה ROOT?

איך בדיוק הוא אמור לעשות "rpm -i" לחבילת המקור אם הוא לא root?

בדביאן, הוא עושה apt-get source name

שחר

rpm -i לחבילת מקור לא מעדכן את ה־rpm database של המערכת ולכן לא דורש הרשאות root. בתנאי שהגדרת את ה־rpmdir כמו שצריך ב־rpmmacros .

> "אין יצירת חבילות קוד מקור"
איך בדיוק אתה מפיץ קוד מקור של תוכנה ביחד עם כל המידע הדרוש לבנית החבילה בדביאן? אם הבנתי אותך נכון, אתה צריך להפיץ שני קבצים: את הכדורזפת של התוכנה ואת החבילה הבינארית.
ב-RPM אתה יכול או להפיץ את קובץ ה-SPEC בתוך כדור הזפת של המקור (ו-RPM יכול לבנות את התוכנה ישר מתוך הכדורזפת עם הטג tb- ) או להפיץ חבילת RPM מיוחדת מסוג source RPM שמכילה עותק של כל הקבצים הדרושים לבניה, שניה לפני שהרצת את התהליך, כך שמשתמשים שלא יודעים איך לקמפל תוכנות מסוגלים לבנות תוכנה מקוד מקור בפקודה אחת. RPM גם מנהל תלויות של בניה כך שאם חסרות לך חבילות devel בשביל הבניה אז RPM יזהיר אותך מראש.
עד כמה שאני יודע, ל-RPM יש את מערכת הבניה מקוד מקור הכי מוצלחת מתוך מנגנוני ניהול החבילות (מלבד ports ו-emerge, אבל להם יש בעיות קשות אחרות של-RPM אין).

> "יצירת החבילה וה-netadata אינו פשוט" - זה פשוט לא נכון ... הבעיה היא שהחבילות שנוצרות כך הן באיכות ירודה יותר..

אז בעצם אתה אומר שזה לא נכון, כי יש כלים אלטנרטיביים שמפשטים את העבודה, אבל בגלל שהם גרועים ביותר אף אחד לא משתמש בהם. אז זה כן נכון ?

1. בניגוד למה שאני הבנתי מהתגובה שמעלי (ולא ממה ששחר כתב), אין צורך להפיץ את החבילה הבינרית כחלק מהחבילה של קוד המקור. כדי להפיץ את החבילה של קוד המקור יש שנים או שלושה קבצים: dsc ,*.tar.gz.* ובדרך כלל נוסף גם הקובץ השלישי, .diff.gz.*.
2. בענין ה metadata, לדעתי הכלים טובים ואחרי נסיון גם בניה ידנית נותנת איכות טובה.

אתה מצרף לעץ המקור את תיקיית debian. כדי לבנות את החבילה אפשר להריץ את הקובץ debian/rules (שהוא בעצם makefile) או בעזרת dpkg.

תלוי למה אתה קורא "מערכת הבניה".

אם אתה מתכוון לייצירת DEB באמצעות dpkg-deb, הרי שאתה פשוט מייצר את עץ הקבצים ו-directory עם הקבצים שמתארים את החבילה, וזהו. פשוט וקל. יש בעיות רגילות עם השיטה הזו. למשל, איך מייצרים שוב את אותו העץ, איך מוודאים שאין התנגשויות, ועוד בעיות שקשורות לבקרת איכות. בגלל זה, אף אחד לא משתמש בשיטה הזו.

מה שכן עושים, בונים makefile שמייצר את העץ אחרי שקימפל את קבצי המקור. במובן זה, בניית חבילה בדביאן (על ידי הרצת debian/rules או ע"י הרצת dpkg-buildpackage) פשוטה לפחות כמו, אם לא יותר, מאשר rpmbuild -ba.

אחד היתרונות, וזה גם מה שגורם לטענה שניהול ה-patches יותר קשה, זה שאותו תהליך שבונה את החבילה הבינארית בונה גם את הפצת קוד המקור. במילים אחרות, נבנה גם קובץ diff יחיד שהופך את קוד המקור upstream לקוד המקור שאתה צריך בשביל הקומפלציה.

הפן החיובי הוא שייצירת החבילה לא דורשת כל פעם ליצור קובץ diff בעצמך. אתה עורך את קוב המקור כרגיל, וקובץ ה-diff נוצר אוטומטית. בפן השלילי, כך לא ניתן לעקוב בקלות אחרי כמות גדולה של שינויים ממקורות שונים. כפי שציין צפריר, בשביל זה יש את dpatch.

בכל מקרה, התחליף ל"חבילת מקור" הוא שלושה קבצים בדביאן. קובץ המקור המקורי (כמו בג'נטו), קובץ קטנטן שנותן תמצית על החבילה, וקובץ עם patch שמוסיף את התמיכה בבנייה לדביאן אל תוך קובץ המקור המקורי. כל הכלים של דביאן יודעים לטפל בשלישיה הזו כיחידה אחת, כך שחוויית המשתמש לא נפגעת (ואולי אף להיפך).

שחר