ואחרי שראיתי את porthole... תן לו בדסקטופ!

DEBIAN SARGE

סארג' מאפשרת שליטה כוללת בחבילות המותקנות מקוד מקור? (בתור הפצה בינארית, זה נשמע די תמוה) בסארג' אפשר להתעדכן ברמת Bleeding Edge? (ברור שלא - דביאן סיד, שנחשבת ליציבה ולפחות מעודכנת לעומת ג'נטו, מתעדכנת כשבועיים לפני סארג'. בג'נטו אני משתמש בKDE 3.4B2 באופן שוטף מהebuilds הרשמיים. מה קורה בדביאן?).
בתור אחד שניסה את דביאן סיד, ולאחר מכן את ג'נטו, אני מעדיף באופן גורף את האחרונה-ולא מוכן לוותר עליה כרגע.

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

תפריד בין bleeding edge לבין production . המשמעות המילולת של bleeding edge הוא "קצה חד של תער". אם לא נזהרים נחתכים ממנו.

במערכת production אתה רוצה לדעת שהחבילה באמת עובדת לפני שאתה מתקין אותה. המהדרין יחזיקו מערכת נסיון ויתקינו עליה את כל העדכונים לבדיקה לפני שהם יכניסו אותה למערכת ה־production.

אתה רוצה להוסיף מקורות משלך: אתה מוסיף מקור חבילות אחר בנוסף למקור החבילות הרגיל.

"שליטה בחבילות ברמת קוד מקור" הוא אמצעי. אילו מטרות אתה רוצה להשיג בעזרתו? תן דוגמה.

צפריר

כמשתמש ג'נטו אני יכול לעבוד עם חבילות עם או בלי keywords של ~x86 (חבילות לא יציבות) - כאלו שנבדקו יותר ועדכניות פחות, או להפך.

אני מעדיף להשתמש בkeywords, אך מערכות production צריכות חבילות בדוקות ויציבות דיים.
עם זאת, על מערכות ללא keywords ניתן להתקין חבילות יוצאות דופן עם keywords, באמצעות פקודה אחת פשוטה (ACCEPT_KEYWORDS="~x86" emerge packagemame).

הוספת מקורות משלי: גם כאן השקיעו מחשבה בג'נטו, ולקחו את זה צעד אחד קדימה: ניתן לאמרג' (מלשון emerge) חבילות לא רק ממקורות מהרשת, אלא אפילו באמצעות ebuild שנמצא על המערכת המקומית (PORTAGE_OVERLAY).

שליטה בחבילות ברמת קוד מקור: אתה רוצה להתקין את KDE ללא חבילות של גנום? פשוט וקל:
USE="-gnome" emerge kde
אתה רוצה לשנות את רמת האופטימיזציה והאגרסיביות של הקימפול? שנה/הוסף/הסר CFLAGS או CXXFLAGS בetc/make.conf/

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

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

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

צפריר

סליחה

אפשר לעשות חבילות בינאריות בג'נטו, גם היום.

לא מכיר, אבל אאמין לך.

השאלה האמיתית היא: כמה קשה לי בתור משתמש ג'נטו למשוך ebuild, לבנות ממנו חבילה בינארית ואז להפיץ אותה ל-n מכונות ?
אם יש לזה רמת סיבוכיות יותר גבוהה מ- O(1) , אז לא תודה.

אפשר להוסיף להגדרה של /etc/make.conf שיכין כל פעם שהוא מסיים לקמפל משהו חבילה בינארית, ואז יש לך אותה בספרייה. פשוט תשתף ת' ספרייה הזאת, ותשיג ת' תוכנות בעזרת emerge -K.
אפשר גם לעשות זמנית בניית חבילה עם emerge -b נדמה לי.

יש לי הרגשה שזה יותר קרוב ל O של N יש לי הרגשה שכל בג ידרוש ממך להתקין שוב...
כי הסבירות שזה יעבוד בלי תקלות על כל מחשב הוא גבוהה..

אז בעצם אתה אומר שאם
- אני מוודא ביד שכל המכונות מותקנות באותה תצורה (ע"י קמפול מקוד מקור כמובן)
- ושאני בונה בעצמי מנגנון של repository
- ואני שאני דואג בעצמי לסביבת הבניה שלי
- ושאני מכין חבילות בינאריות ביד לפני הפצה
- ושאני דואג להפיץ את החבילות בעצמי לכל מכונה
אז אקבל מערכת מושלמת לניהול תוכנה.

ובכן - רוב הפצות הלינוקס מכילות בעצמן מנגנון שכזה - הוא יותר בדוק ועם אינטגרציה גבוהה יותר מאשר כל דבר שאני יכול לקנפג ביד בעזרת עריכת קבצי make.conf. כשאני בא לבחור הפצה, אחד הקרטיריונים החשובים ביותר היא קלות הניהול של מכונות מרובות - וג'נטו פשוט לא בליגה של הפצות כמו Fedora, Debian, SuSE או .Mandrake