פורסם: 13/07/2004 - 13:51
נושא ההודעה:
|
אני מכיר את המערכת של autopackage דיי טוב , וכמו שציינתי הבסיס העיקרי הוא המנגנון של realoc (בתקוה שלא טעיתי בשם). השמוש ב realoc יכול להתבצע גם במנגוני התתקנה הקימים , הבעיה בשמוש ב autopackage זה שאין להם שום כוונה להתקין ולייצר חבילות גדולוץ לדוגמה כמו KDE (תקרא קצת באתר) כל מה שהם רוצים זה לאפשר לך להתקין תוכניות קטנות שמשתנות בתדירות גבוהה והמשתמש רוצה או צריך לעדכן אותם כל הזמן (עיין ערך קצב השנויים בפרוטוקול של yahoo) , לכן מה שנוצר הוא שמשתמש צריך להכיר שכבת פעולה נוספת שרק מקשה , ובנוסף אין דרך קלה יותר להתקין תוכנות מ apt-get ודומיהם אם זה תוך שמוש בשורת פקודה בתוכניות כמו knaptic או בהתקנת web בסגנון klick .
ועדיין לא ענית על השאלה מה קורה אם משהו לא יצר חבילת autopackage ?
|
|
חזרה לתוכן הדיון |
פורסם: 13/07/2004 - 13:55
נושא ההודעה:
|
אם חבילת autopackage תהיה הדרך הכי קלה ליצור בינארי שיהיה אפשר להתקין אותו בצורה ידידותית על כל ההפצות ובכל הגרסאות שלהן, אז הבינארי הראשון שייווצר יהיה מן הסתם autopackage.
הבעיה היום שאם המפתח צריך להכין בינארים הוא צריך להכין בינארים לאלף גרסאות שונות, ולכן, או שהוא מכין רק שניים שלושה, או שהוא מוותר מראש, או שקמות להן כל מיני התקנות לא סטנדרטיות - ע"ע firebird ו- openoffice.
ואם autopackage יעדכן את rpm על החבילה המותקנת ויסתנכרן איתו, אז באמת תפסנו שני ציפורים במכה אחת.
_________________ In theory, there is no difference between theory and practice.
In practice, there is.
נערך לאחרונה על-ידי Nirro בתאריך 13/07/2004 - 13:56, סך-הכל נערך פעם אחת
|
|
חזרה לתוכן הדיון |
פורסם: 13/07/2004 - 13:55
נושא ההודעה:
|
Nirro, אני משנה קצת את החזון שלך...
שמעתי (לא ראיתי) שגוגל רוצה לשים את כל מערכות ההפעלה על השרתים שלהם וכולם יוכלו להכנס ל"מחשב" שלהם דרך כל מקום בעולם....
במצב כזה אפשר לדבר על הרעיון של autopackage שבו כל הספריות גלובליות אבל על מחשב של STAND ALONE אין אפשרות שכל הספריות יהיו מותקנות ובטח לא לדאוג לתלויות שהן לא ספריות...
חוץ מזה מה שאני אוהב בלינוקס זה ההתקנה מקוד מקור (האפשרות לשנות משהו בקוד לפני ההתקנה), למרות שאני שונה את הקימפול (ש-נ-י-ם עד שזה גומר)
|
|
חזרה לתוכן הדיון |
פורסם: 13/07/2004 - 14:03
נושא ההודעה:
|
Nirro : | אם חבילת autopackage תהיה הדרך הכי קלה ליצור בינארי שיהיה אפשר להתקין אותו בצורה ידידותית על כל ההפצות ובכל הגרסאות שלהן, אז הבינארי הראשון שייווצר יהיה מן הסתם autopackage.
הבעיה היום שאם המפתח צריך להכין בינארים הוא צריך להכין בינארים לאלף גרסאות שונות, ולכן, או שהוא מכין רק שניים שלושה, או שהוא מוותר מראש, או שקמות להן כל מיני התקנות לא סטנדרטיות - ע"ע firebird ו- openoffice.
ואם autopackage יעדכן את rpm על החבילה המותקנת ויסתנכרן איתו, אז באמת תפסנו שני ציפורים במכה אחת. |
כן זה יהיה נחמד מאוד אבל זה לא היעוד של autopackage ,וכמובן שהדרך היחידה להשיג דבר כזה הוא על ידי הגדרה ושמוש בסטנדרטים ולכן אין שום סיבה ליצור שכבת סיבוך נוספת.
|
|
חזרה לתוכן הדיון |
פורסם: 13/07/2004 - 14:35
נושא ההודעה:
|
maor : | Nirro : | אם חבילת autopackage תהיה הדרך הכי קלה ליצור בינארי שיהיה אפשר להתקין אותו בצורה ידידותית על כל ההפצות ובכל הגרסאות שלהן, אז הבינארי הראשון שייווצר יהיה מן הסתם autopackage.
הבעיה היום שאם המפתח צריך להכין בינארים הוא צריך להכין בינארים לאלף גרסאות שונות, ולכן, או שהוא מכין רק שניים שלושה, או שהוא מוותר מראש, או שקמות להן כל מיני התקנות לא סטנדרטיות - ע"ע firebird ו- openoffice.
ואם autopackage יעדכן את rpm על החבילה המותקנת ויסתנכרן איתו, אז באמת תפסנו שני ציפורים במכה אחת. |
כן זה יהיה נחמד מאוד אבל זה לא היעוד של autopackage ,וכמובן שהדרך היחידה להשיג דבר כזה הוא על ידי הגדרה ושמוש בסטנדרטים ולכן אין שום סיבה ליצור שכבת סיבוך נוספת. |
למה לא הייעוד ? את הכל לקחתי מהאתר שלהם.
אני מסכים איתך שהדרך הנכונה היא בתאום סטנדרטים, אבל אז יגידו שזה פוגע בחופש...
מה דעתך על רעיון האייקונים ?
mad_dr : לא הבנתי בדיוק למה התכוונת.
_________________ In theory, there is no difference between theory and practice.
In practice, there is.
|
|
חזרה לתוכן הדיון |
פורסם: 13/07/2004 - 14:39
נושא ההודעה:
|
Nirro כתב:
> תוכנת קצה לא צריכה להיות תלויה
> בתוכנת קצה אחרת, אלא רק בספריות.
> כל עוד מקפידים שכל הספריות מותקנות
> גלובאלית, לא תהיה בעיה של תלויות
מכאן שהמערכת הזו מאוד מוגבלת. היא היא מתיימרת להתקין רק תוכנות.
אבל הזכרתי שני מקרים שבהם המודל שלך לא יעזור:
1. אם התוכנה כוללת ספריות שתוכנות אחרות משתמשות בהן. זה נפוץ מאוד בתוכניות KDE. הפצת מוזילה כוללת את libnspr ואת libgtkmozembed . למעשה, רוב הקוד של מוזילה בא בצורת ספריות.
2. תוספים
איך מתקינים חבילה של תוספים לחבילה אחרת? (ר' חבילות של תוספים למוזילה בדביין)
|
|
חזרה לתוכן הדיון |
פורסם: 13/07/2004 - 14:49
נושא ההודעה:
|
Nirro כתב:
> אם autopackage יעדכן את rpm על החבילה המותקנת ויסתנכרן איתו
rpm פועל ברמת המערכת. autopackge פועל עבור משתמש יחיד. לא הגיוני לעדכן את מצאי החבילות של כל המערכת כאשר רק למשתמש מסויים נוספה חבילה. תנסה לחשוב בעצמך מה זה יכול לשבור.
תנסה לחשוב מה יקרה כאשר תמחוק את אותו משתמש ותיצור משתמש חדש בלי אותן חבילות autopackage . אף־אחד לא יטרח לעדכן את rpm .
(ואני לא מדבר על בעיות אבטחה אפשריות)
|
|
חזרה לתוכן הדיון |
פורסם: 13/07/2004 - 14:53
נושא ההודעה:
|
Nirro : |
לגבי תוכניות עם מספר executables - זה פשוט דוגמה מצויינת לחוסר ידידותיות למשתמש. אפילו דביאן החליטו שלכל executable יהיה חבילה נפרדת.
|
הדוגמא הכי פשוטה - OO.o.
בכל מקרה, אני לא הייתי משתמש בדבר כזה.
|
|
חזרה לתוכן הדיון |
פורסם: 13/07/2004 - 14:59
נושא ההודעה:
|
מה שאני התכוונתי זו מערכת הפעלה בסיגנון:
http://www.whatsup.org.il/modules.php?op=modload&name=News&file=article&sid=2234
שכל המערכת לא נצאת על המחשב אלא על שרת...
(פשוט שמעתי שגוגל רוצים גם לעשות משהו דומה...)
|
|
חזרה לתוכן הדיון |
פורסם: 13/07/2004 - 15:50
נושא ההודעה:
|
צפריר : | Nirro כתב:
> אם autopackage יעדכן את rpm על החבילה המותקנת ויסתנכרן איתו
rpm פועל ברמת המערכת. autopackge פועל עבור משתמש יחיד. לא הגיוני לעדכן את מצאי החבילות של כל המערכת כאשר רק למשתמש מסויים נוספה חבילה. תנסה לחשוב בעצמך מה זה יכול לשבור.
תנסה לחשוב מה יקרה כאשר תמחוק את אותו משתמש ותיצור משתמש חדש בלי אותן חבילות autopackage . אף־אחד לא יטרח לעדכן את rpm .
(ואני לא מדבר על בעיות אבטחה אפשריות) |
http://autopackage.org/gallery.html
טוב האתר נפל, מה שרציתי להראות בתמונות הוא שאפשר להתקין גם כמשתמש וגם גלובאלי, לפי בחירת המשתמש, וכן שהספריות מותקנות גלובאלי.
_________________ In theory, there is no difference between theory and practice.
In practice, there is.
נערך לאחרונה על-ידי Nirro בתאריך 13/07/2004 - 16:21, סך-הכל נערך 3 פעמים
|
|
חזרה לתוכן הדיון |
פורסם: 13/07/2004 - 15:52
נושא ההודעה:
|
mad_dr, שמעת על פרוייקט בשם zero-install ?
http://zero-install.sourceforge.net/
לדוגמה, אתה יכול להריץ את rox-filer ישירות מהאינטרנט בלי להתקין אותו.
הפעלות נוספות יפעילו את rox-filer מה-cache.
_________________ In theory, there is no difference between theory and practice.
In practice, there is.
|
|
חזרה לתוכן הדיון |
פורסם: 13/07/2004 - 16:02
נושא ההודעה:
|
The-Q : | Nirro : |
לגבי תוכניות עם מספר executables - זה פשוט דוגמה מצויינת לחוסר ידידותיות למשתמש. אפילו דביאן החליטו שלכל executable יהיה חבילה נפרדת.
|
הדוגמא הכי פשוטה - OO.o.
בכל מקרה, אני לא הייתי משתמש בדבר כזה. |
Q אלה בעיות קטנות שניתן לפתור אותן בקלות מרובה, כמו למשל להכניס את כל האייקונים לספרייה, ולגרור את כל הספרייה... (סתם עלה לי לראש בלי הרבה מחשבה)
מה יותר פשוט מזה ?
_________________ In theory, there is no difference between theory and practice.
In practice, there is.
|
|
חזרה לתוכן הדיון |
פורסם: 14/07/2004 - 01:05
נושא ההודעה:
|
סוף סוף האתר שלהם חזר, כך שניתן לבדוק על מה המהומה.
מדובר ברעיון רע, שיצור בעיות שמערכות ניהול חבילות חבילות שקיימות כיום פתרו מזמן. נראה שלא מעריכים את המערכות האלה מספיק.
אחת הבעיות הגדולות ביותר בעבודה כזו היא אבטחה (ולא מה שנדון בדיון כאן). כל מערכות ניהול החבילות יורידו לך אוטומטית גרסאות חדשות של החבילות אם יש עדכוני אבטחה, יחד עם התיקונים. זה חלק מהעדכון השוטף של המערכת (ולא משנה איזו: apt, urpmi, portage, וכן הלאה).
מה קורה במקרה של autopackage ? ואם כל משתמש מחזיק גרסה שונה בתיקיה שלו ? מי אחראי לעדכונים ? ואם התקינו 50 חבילות בעזרתה, וכל אחת מאתר אחר ? מה אז ?
מאגרי חבילות של הפצות הופכות פעולה כזו לפשוטה ולא משהו שצריך לחשוב עליו.
ומה אם החבילה לא קיימת במאגר ? יש למשתמש מספר אפשרויות:
1. לחפש מאגר שמכיל את החבילה.
2. לבקש ממישהו שיתחזק מאגר כזה או לבנות חבילה עבורו.
3. לבנות בעצמו מהמקור.
זה משמש כמסנן טוב. מי שיכול לעשות את 2 או 3 בד"כ גם יוכל ויעקוב אחר עדכונים שצריך לבצע.
בקשר לזה שהמערכת לא דואגת לספריות אלא רק ליישומים, המצב גרוע מאוד ויוביל למערכות שמנות ביותר. ניקח את גימפ לדוגמא: יש לה מספר אפשרויות של פלאגינים. גם בפרל, גם בפייתון. אם אתה רוצה את אלו שבפייתון, אתה צריך גם את pygtk.
ומה קורה אם תרצה להתקין את azureus לדוגמא ? אז תצטרך גם jre (ובמקרה הרע SWT, אך הם אורזים אותו בד"כ בפנים).
זה מוביל למערכת שמנה מאוד שצריכה בעצם כל ספריה שקיימת. ואם autopackage יטפלו גם בתלויות, הם לא פותרים כלום. הם פשוט בונים עוד מערכת ניהול חבילות ומוסיפים לבלאגן (ראה מקרה RSS ו-ATOM).
לא כל דבר צריך "לטמטם". ישנה אמרה באנגלית שנותנת קונטרה ל-KISS (לא זוכר בדיוק, ציטוט חופשי):
"אם תבנה מערכת שגם משתמשים מטומטמים יכולים להשתמש בה, רק משתמשים מטומטמים ישתמשו בה בסופו של דבר".
|
|
חזרה לתוכן הדיון |
פורסם: 14/07/2004 - 10:46
נושא ההודעה:
|
בנוסף לכך לפי הבנתי זה יהיה פרוייקט בעל סיבוכים אינסופיים לנסות לבנות מערכת חבילות שתעבוד על כל ההפצות. הרי כל הפצה חופשית
לשנות דברים קטנים או גדולים במערכת, מיקומים של ספריות וכו'.
לך תנסה לשכנע את אנשי דביאן, פדורה, ג'נטו , מנדרייק וכל היתר להסכים לתקן אחד, ניסית פעם לשכנע שלשה אנשים לעשות משהו בצורה זהה ? ...
מה רע במצב כמו שהוא היום ? כל פרוייקט תוכנה משחרר את קוד המקור ולא צריך לדאוג ל1000 הפצות שונות. הפצה שרוצה להכליל את החבילה מכינה בינארי ודואגת שהחבילה תתפקד ללא התנגשויות.
המשתמש מתקין את החבילות בעזרת מנהל חבילות.
אם כבר מדברים על "משתמשים הדיוטים" אז לפי דעתי העתיד דווקא יהיה לא בכוון של חבילות שהמשתמש מתקין, אלא שהמשתמש מריץ את האפליקציה מהשרת והמחשב המקומי רק מציג את הממשק.
|
|
חזרה לתוכן הדיון |
פורסם: 14/07/2004 - 11:02
נושא ההודעה:
|
mksoft, המערכת לא מטפלת היום בעדכונים, זה נכון. אבל בעתיד היא מתכוונת לעשות את זה.
במאמר של החזון לטווח ארוך שנתתי בהתחלה, מדובר על מערכת עדכונים שדומה לפי מה שאני הבנתי ל- up2date של רד-האט.
לגבי ספריות - זה פשוט לא נכון. autopackage לא מכניסה את כל הספריות סטטית, והיא לא מטפלת רק בתוכנות. להיפך, הצצה חטופה בתמונה הזאת :
וזאת :
אתה יכול לראות שהמערכת שואלת את המשתמש אם הוא רוצה להתקין globally או locally,
וכן כשחסרה ספרייה, הספרייה פשוט מורדת מהאינטרנט ומותקנת.
בניגוד ל-apt שבו יש מאגר עצום וריכוזי של תוכנות, המאגר של autopackage הוא מאגר של simlinks ברשת, שגורם לכך שכל אחד יכול להכין autopackage מהיישום/ספרייה שלו, ורק צריך לעדכן (בצורה מסויימת, מאובטחת יותר או פחות) את המאגר של autopackage.
וחשוב להזכיר, autopackage לא מתיימרת להחליף את rpm, אלא להוות אפשרות נוחה להתקנה מהרשת, בעוד rpm עדיין ישמש להתקנה מהדיסק - התקנה ראשונית.
אחת מה-todo שלהם הוא להפשר אינטגקציה בין autopackage ל-rpm, כך שברגע שנתקין חבילה עם autopackage, המאגר של rpm יתעדכן בהתאם (כנ"ל dpkg ואחרים).
איתן, תחשוב כמה כוח אדם מתבזבז על הכנת חבילות, אם תהיה מערכת אחת שיודעת להתקין בינארים על כל ההפצות, לא משנה כמה הן שונות אחת מהשנייה, לא היית מנצל אותה ?
_________________ In theory, there is no difference between theory and practice.
In practice, there is.
נערך לאחרונה על-ידי Nirro בתאריך 14/07/2004 - 11:09, סך-הכל נערך פעם אחת
|
|
חזרה לתוכן הדיון |
פורסם: 14/07/2004 - 11:06
נושא ההודעה:
|
כנראה שאי אפשר להבין עד שמנסים.
אני מזמין את כל המתנגדים לנסות את המערכת ולהתקין משהו בעזרתה (יש כמה תוכנות להדגמה באתר שלהם), נא לזכור שהמערכת עדיין בפיתוח ולא מושלמת, אבל לי היא עבדה בכל אופן, ואני התלהבתי.
_________________ In theory, there is no difference between theory and practice.
In practice, there is.
|
|
חזרה לתוכן הדיון |
פורסם: 14/07/2004 - 11:37
נושא ההודעה:
|
תראה ניסיתי ראיתי קראתי ובדקתי כל מה שאפשר לעשות , בנק' התחתונה אתה יכול אולי להתעלם מזה אבל זה מוסיף עוד רמת סיבוכיות , השמוש ב realoc לא קשור לשמוש ב autopackages אלה לתוכנות עצמם לדוגמא הספריות של kde משתמשות היו ב realoc , מה שזה בא לאפשר זה להתקין תוכניות לכל מקום כלשהו בלי שהוגדר מראש בעת הקמפול , במנגנון הנ"ל יכולים להשתמש בכל מנהל חבילות , אז תסביר לי מה מחדש ה autopackage חוץ מהתכונה של אינפלציה דוהרת במנהלי חבילות שקיימת בהפצות לינוקס היום , אם נמנה כמה : portage , apt-get , urpmi ,pacman , swart ,autopackage , yum וזוהי רק התחלה מה שצריך הוא סטנדרטים , אמרת את זה יפה autopackage מתימר להשיג יכולת התקנה על כל הפצה ומתימר זאת המילה החשובה , ללא סטנדרטים ושיתוף פעולה לעולם לא נגיע לשם (לא שבהכרח זה דבר טוב).
|
|
חזרה לתוכן הדיון |
פורסם: 14/07/2004 - 11:50
נושא ההודעה:
|
תשמע, מכל האינפלציה של מערכות התקנה משהו בטח ייצא טוב.
אני מהמר על autopackage. יכול להיות שאני טועה.
אבל מה שאני רואה פה בעיקר זו צרות מחשבתית בסגנון : אם זה עובד אל תגע בו.
או - "תעזוב אותי מכל הרעיונות המוזרים האלה, apt עובד בסדר, אז אל תגע בו."
וחבל, רק המחשבה היצירתית והרצון לשפר (ולא עמידה על השמרים) הביאה את לינוקס למצב שבו הוא נמצא כיום.
_________________ In theory, there is no difference between theory and practice.
In practice, there is.
|
|
חזרה לתוכן הדיון |
פורסם: 14/07/2004 - 12:10
נושא ההודעה:
|
הדיון ארוך ועוד לא הספקתי לקרוא את כולו אבל עלה לי משהו שהייתי חייב לכתוב,
אם הזכירו אז תודיע ו לי סליחה.
ובכן הרעיון נחמד אבל שוכחים דבר חשוב לגמרי,
לכל הפצה יש Prefix שונה בתכלית.
אצל אחת התוכנות מותקנות ב
/usr
השניה ב/usr/local השלישית ב/usr/share/apps/ ולכו תדעו מה עוד יש.
בקיצור,
אם אני אתקין את אחת מהתוכנות משם, אני אקבל בלגן רציני במערכת שלי,
קודם כל היא תתקין לי ספריות במיקומים שגוים,
אחרי זה היא גם לא תעדכן את המנהל חבילות שלי שהספריות האלו מותקנות, ואת הפורטג' שלי ישתגע לגמרי.
אני אישית לא אתקין כלום ככה.
|
|
חזרה לתוכן הדיון |
פורסם: 14/07/2004 - 12:19
נושא ההודעה:
|
autopackage תהיה מספיק חכמה כדי לזהות באיזה הפצה אתה משתמש ולהתקין את הדברים למקומות "הנכונים" על פי ההפצה שלך.
סינכרון עם מנהלי החבילות הקיימים (במקרה שלך portage) מתוכננת, אבל תיושם בשלב מאוחר יותר, רק אחרי גרסה 1. (היום הם בגרסה 0.5)
_________________ In theory, there is no difference between theory and practice.
In practice, there is.
|
|
חזרה לתוכן הדיון |
פורסם: 14/07/2004 - 12:28
נושא ההודעה:
|
Nirro : | autopackage תהיה מספיק חכמה כדי לזהות באיזה הפצה אתה משתמש ולהתקין את הדברים למקומות "הנכונים" על פי ההפצה שלך.
סינכרון עם מנהלי החבילות הקיימים (במקרה שלך portage) מתוכננת, אבל תיושם בשלב מאוחר יותר, רק אחרי גרסה 1. (היום הם בגרסה 0.5) |
במילה אחת, חסר טעם? (כלמור בשתי מילים )
קודם כל, מה קורה אם אני משתמש בהפצה קטנה, eg: Onebase-Linux, שהיא רק בתחילת דרכה?
או שנגיד אני משתמש ב... נגיד מנדרייק 11 שיצא בדיוק אתמול לאינטרנט? אז אני יכול להמתין הרבה זמן עד שתופיע התמיכה בהפצה שלי.
ואם לא תהיה תמיכה בהפצה שלי,
אני אקבל כמו שמארתי באלאגן.
ואגב, הדבר הזה יהפוך את לינוקס להיות דומה למדי כמו ווינדוס, כל תוכנה יש לה את החבילות שלה.
בעיקר אם כל המשתמשים על אותו המחשב יתקינו את אותה התוכנה על המשתמש שלהם לבד (ולא כROOT), ובעיקר אם לא לכולם יש את החבילות, ואז מה?
אותם ספריות הנחוצות לתוכנה, יותקנו על כל משתמש בנפרד.
ואז זה מזכיר את ווינדוס, כל תוכנה מקומפלת סטאטית וגורמת להכל להיות בלגן אחד גדול, ולתפוס נפח רציני.
|
|
חזרה לתוכן הדיון |
פורסם: 14/07/2004 - 12:38
נושא ההודעה:
|
יש לי רעיון מאד פשוט.
צריך תוכנה שיודעת לקחת קבצי source ולקמפל אותם ללא
התערבות המשתמש, לשים כל קובץ במקום המתאים להפצה,
להוסיף את קיצור הדרך של התוכנה לתפריטים של KDE ו GNOME.
כך לא יהיה צורך בחבילות בינאריות עבור כל הפצה.
|
|
חזרה לתוכן הדיון |
פורסם: 14/07/2004 - 12:42
נושא ההודעה:
|
כמה פעמים אני צריך להגיד באותו פתיל ש- ספריות לא מותקנות בספרית המשתמש.
בוא נגיד את זה עוד כמה פעמים :
ספריות לא מותקנות בספרית המשתמש
ספריות לא מותקנות בספרית המשתמש
ספריות לא מותקנות בספרית המשתמש
ספריות לא מותקנות בספרית המשתמש
לגבי תמיכה בהפצות צעירות - אני לא יודע איך בדיוק ה-autopackage עובד, ואיך הוא מזהה את מיקום הספריות, כמו שאמרתי זה היוריסטי, כלומר יש סיכוי כלשהו לטעות.
בכל אופן זו שאלה טובה שצריך לשאול בפורום הפיתוח של התוכנה, אבל לא לשלול את כל הסיפור מראש בגלל זה, יא-אללה.
מה זה תחרות מי ימצא יותר פגמים ?
_________________ In theory, there is no difference between theory and practice.
In practice, there is.
|
|
חזרה לתוכן הדיון |
פורסם: 14/07/2004 - 13:12
נושא ההודעה:
|
בסוף הצלחתי למצוא את החלק החשוב ב autopackage נקרא binreloc
מידע על זה כאן :
http://autopackage.org/docs/binreloc/
זה פותר את הבעיה של מיקומים סטטיים לאחר קימפול של חבילה , ולכן מאפשר גמישות בהתקנה .
|
|
חזרה לתוכן הדיון |
|