מנהל חבילות אולטימטיבי ללינוקס

משתמשי לינוקס תמיד מתגאים במנהלי החבילות של ההפצה שלהם: apt, aptitude, yum, yast, pacman ועוד… לדעתי לא צריך להתגאות כ"כ במנהלי החבילות, מפני שכולם סובלים מאותה בעיה מהותית, שמקשה מאוד על משתמשי לינוקס: בעיית התלויות.

במערכות הפעלה אחרות (חלונות, IOS, אנדרויד, BSD) כל חבילת תוכנה מכילה בדר"כ את כל רכיבי התוכנה הדרושים להפעלתה. נכון: יש חריגים (נניח תוכנות שתלויות בגרסה מסויימת של NET.), אבל בדר"כ רוב התוכנות ניתנות להתקנה קלה ופשוטה יחסית.

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

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

הייתי רוצה לראות פתרון דומה בלינוקס, ומוזר לי מאוד שעד היום אף חברה לא ניסתה לפתח פתרון דומה. היום רוחב הפס או גודל הדיסק לא מהווה בעיה. הפצה אידיאלית מבחינתי תכיל גרעין לינוקס (Kernel) מאוד יציב שיכיל תמיכה רחבה בהתקני חומרה. הוא לא חייב להיות החדשני ביותר, וניתן ליצור גם מס' Kernels ברמת יציבות שונה (כך שאולי הקרנל החדשני ביותר יתמוך בחומרה חדשה יותר, אבל רוב המשתמשים אולי ירצו להשתמש ב- kernels ישנים ויציבים יותר). Manjaro מיישמת רעיון זה ומאפשרת מעבר פשוט מאוד בין Kernels שונים.

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

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

My Signature
פורסם בקטגוריה לינוקס ותוכנה חופשית. אפשר להגיע לכאן עם קישור ישיר.

11 תגובות בנושא מנהל חבילות אולטימטיבי ללינוקס

  1. מאת levi0x0x‏:

    עושה חשק לעבור ל – bsd (:

    אבל לפי דעתי זה יותר נוח למפתח לכתוב קוד ופשוט להגדיר את "התלויות"
    בחבילה (deb,rpm,etc…)
    היום רוב ההפצות מבוססות על הפצות אחרות (, etc..debian,redhat) הייתי שמח לראות
    הפצה חדשה שתחדש קצת..

    מעניין (:

  2. מאת ik_5‏:

    בווינדוז יש המון בעיות עם דרישות.
    זה נכון שתוכנות ההתקנה מכילות את כל הקבצים שצריך, אבל הן לפעמים מתנגשות עם התקנות של תוכנות אחרות.
    יותר מזה, dll בגרסה איקס מתנגש בdll אחר הקיים. שם יש resource שאומר מה הגרסה. אז מה שקורה זה שאתה או שם אותם בספרייה המקומית של התוכנה, ואז יש לך כפילויות, או שם אותם ב system/32 ואז זה גלובלי ומתנגש.

    בBSD יש אותה הבעיה. זו הסיבה שיש לך הרבה מקומות שתוכנות יכולה להתקין דברים. לפעמים תמצא את ההתקנה תחת /usr/local ולפעמים תחת /usr/lib ולפעמים יהיו עוד מקומות שונים.

    הגישה של לינוקס גם בעייתית, אבל לפחות היא מנסה לפתור את הבעיות של ווינדוז וBSD.

    ד"א כיום יש כמה גישות חדשות לגבי ה jail בלינוקס. החל מ cgroups, ועד למערכות שגורמות לווירטואליזציה להראות מיושנת (ע"ע docker למשל)

  3. מאת שביט אילן‏:

    הי עידו
    פתרון בדמות מנהל חבילות, אני מניח, היה בזמנו מהפכני (והיום זה הפך לנורמה במוצרים שונים: Google Play, App Store ועוד…).
    לדעתי הבעיה הקיימת בחלונות (גרסאות שונות של DLL) פחות בעייתית מהמצב הקיים כיום (בו מותר רק לגרסה אחת לשהות במערכת ההפעלה: או שאתה מיישר קו אליה או שאתה בחוץ…)
    DLL (או so. בלינוקס) מבחינתי יכולים להיות באותה הספריה בה מותקנת התוכנה עצמה. אם רק התוכנה משתמשת בגרסה הזאת, מה הבעיה שיהיו כפילויות? (נכון, זה פחות מסודר ונקי, אבל יעבוד תמיד).

  4. מאת א‏:

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

  5. מאת elcuco‏:

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

    לדוגמה:
    נניח אתה מריץ תוכנת Qt5 שמכילה ב־LD_LIBRARY_PATH שלה את libpng . נניח שאתה אז רוצה לפתוח קובץ, אז נפתח חלון "פתיחת קובץ" של המערכת, במיקרה שלי זה של KDE4 שהוא משתמש ב־Qt4 והוא משתמש ב־libpng של המערכת. פוף – יש לך שני מופעים של אותה ספרייה בזכרון וזאת הסיבה שזה נפל פעם. כשהשתמשתי ב־arch היישום לא עלה כלל – כי אז לא QtCreator לא סיפק את libpng ומה ששיש במערכת היה חדש מדי (החברה של QT מקמפלים את ה"חבילות" שלהם על אובונטו ישן.. לצורך תאימות). פופס, אותה בעייה.

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

  6. מאת שביט אילן‏:

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

  7. מאת צפריר כהן‏:

    כשאתה כותב "ב־BSD, למשל, חבילת תוכנה נארזת כך שהיא מכילה את כל החבילות הדרושות להפעלתה." למה אתה מתכוון? למנגנוני ה־ports של הפצות BSD השונות? או למערכת ניהול החבילות של PC-BSD?

  8. מאת שביט אילן‏:

    התכוונתי לחבילות (PBI (appcafe ב- PC-BSD:
    http://www.appcafe.org/pc-bsd

    מתוך: http://wiki.pcbsd.org/index.php/AppCafe%C2%AE/10.0

    A PBI file includes all the runtime and library dependencies required by the application. This means that the initial download of a PBI is a large file; but this does not necessarily mean that same amount of space will be used.

  9. מאת צפריר כהן‏:

    איך מתקינים KDE עם מנהל החבילות הזה? האם כל KDE היא חבילה אחת?

  10. מאת BelGoat‏:

    השימוש במנהל החבילות מבחינתי הוא נוחות וסדר
    לדוגמא כאשר רוצים לבנות מערכת שלמה ולהתבסס על repo עצמאי ששומר על אחידות של החבילות והקשרים בינהם.
    אולי עיקר העניין הוא בהסתכלות שונה בין server אל workstation/desktop.
    כאשר אתה עובד בserver לרוב תעבוד עם מה שיש לך ואם אין לך תמצא פתרונות מספיק קרובים (לדוגמא זה שחברות רבות עובדות עם Python 2.6 או Perl 5.08 כי זה מה שRedHat מספקים – אז ממשיכים לממש בעצמך מה שצריך) בשביל שהמוצר/אתר שלך יעבוד
    לעומת זאת למשתמש הבודד שרוצה לנסות את הגרסאות העדכניות ביותר תמיד ימצא התנגשויות בכל מיני מובנים – לכן לפי דעתי חלונות למשתמש היא אפקטיבית כי המשתמש שמתקין תוכנה עדכנים לא יכול לשבור את הקישוריות בתוך הספריות (אין להסיק מכך שאני בעד המבנה של חלונות או שאין שם בעיות משלהן)

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

  11. מאת שביט אילן‏:

    צפריר: אין חבילת PBI של KDE. הזכרתי את המושג PBI כדי להמחיש פתרונות לנושא התלויות.ֲ
    BelGoat: לא פסלתי את השימוש במנהל חבילות. גם לדעתי הוא מאוד נוח. מה שתהיתי זה אם אפשר ליצור מנהל חבילות שלא כ"כ רגיש לנושא התלויות ומאפשר פתרון אחר שלהם.

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

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *