package managment systems PMS

[apoikos]

Σε εμενα πως δεν το έκανε ποτε ; Tο "επικίνδυνα" δεν το καταλαβα. Ως επι το πλειστον είναι notifications αυτα με echos μεσα.

Σου ξαναλέω, το ότι δεν το έκανε σε εσένα δε σημαίνει ότι δεν το κάνει γενικά. Δες παρακάτω.

 

 

Λόγοι για τους οποίους σταμάτησα να χρησιμοποιώ Arch (και άλλα διηγήματα)

 

Σημ: Η παρακάτω σύγκριση δεν έχει σκοπό να καταδείξει ποια διανομή είναι καλύτερη, αλλά το πως μπορείς να χειριστείς τα ίδια πράγματα με διαφορετικούς τρόπους.

 

• Χειρισμός αρχείων ρυθμίσεων.
  - Στο arch linux δυστυχώς δεν υπάρχει "interlocking". Τα αρχεία και το πακέτο παραμένουν σε μη-συνεπή κατάσταση μετά την εγκατάσταση, μέχρι ο χρήστης να τρέξει μια find /etc -name '*.pacnew' και να κάνει merge με το χέρι. Το dpkg από την άλλη απαιτεί από το χρήστη να κάνει χειροκίνητα merge το αρχείο με το χέρι, προτού περάσει στην εγκατάσταση του επόμενου πακέτου. Κατ' αυτόν τον τρόπο δεν υπάρχει περίπτωση να απαιτείται ενέργεια σε ένα configuration file χωρίς να το πάρει είδηση ο χρήστης.
   
  Επίσης η γενικότερη φιλοσοφία του debian είναι να διαχωρίζονται οι ρυθμίσεις του package maintainer από τις ρυθμίσεις του διαχειριστή του συστήματος, και αυτό φαίνεται από τη σπονδυλωτή δομή των αρχείων ρυθμίσεων διάφορων πακέτων (π.χ. apache, bind κλπ), όπου οι ρυθμίσεις του διαχειριστή γίνονται σε ένα conf.local αρχείο, το οποίο ουδέποτε το αγγίζει το σύστημα διαχείρισης πακέτων.
   
  - Ο μηχανισμός του backup δε λειτουργεί σωστά. Παράδειγμα:
  
  1. Εγκατάσταση του πακέτου foo
     
  2. Τροποποίηση του /etc/foo.conf
     
  3. Απεγκατάσταση του πακέτου foo. To /etc/foo.conf σώζεται ως
     /etc/foo.conf.pacsave
     
  4. Επανεγκατάσταση του πακέτου foo. Εγκαθίσταται νέο /etc/foo.conf
     
  5. Απεγκατάσταση του πακέτου foo. Το νέο /etc/foo.conf σώζεται ως /etc/foo.conf.pacsave, σβήνοντας το παλιό. Αυτή η συμπεριφορά είναι απαράδεκτη (το /etc/foo.conf.pacsave δεν ανήκει καν στη λίστα αρχείων του πακέτου). Θα μπορούσε απλά να κρατάει revisions, π.χ. .pacsave, .pacsave.1 κλπ.
     

  To dpkg χειρίζεται το συγκεκριμένο θέμα πολύ καλύτερα, κρατώντας τα configuration files των πακέτων στο filesystem με την απεγκατάσταση και επαναχρησιμοποιώντας τα σε νέα εγκατάσταση (τι νόημα έχει ένα .pacsave στην τελική. Σε περίπτωση που ο χρήστης θέλει όντως να ξηλώσει τα configuration files, υπάρχει το purge.

   

  [*] Προτεραιότητα πηγών

  Στο Arch Linux υπάρχει μια μόνο σειρά προτεραιότητας για τα repositories, αυτή με την οποία δηλώνονται στο pacman.conf. Αυτό έχει ως αποτέλεσμα να μην μπορείς να επιλέξεις ποια πακέτα θες από συγκεκριμένα repositories και να πρέπει να παίζεις με διαφορετικά configuration files ανά περίσταση. Στο debian αυτό λύνεται μια και καλή, κομψά, με το apt pinning. Επίσης, αφήνει ανοιχτό το ενδεχόμενο να κάτεβει από ένα 3rd party repository κάποιο πακέτο ασύμβατο με το [core] και να σκίσει το μισό σύστημα.

   

  [*] Ανοχή σε system-wide ρυθμίσεις

  - Αλλαγή permissions

  Ο pacman δεν παρέχει κανένα μηχανισμό για τη διατήρηση αλλαγμένων

  permissions στο σύστημα. Παράδειγμα:

  1. Εγκατάσταση του screen
     
  2. Αφαίρεση του setuid bit από το /usr/bin/screen-4.0.3
     
  3. Επανεγκατάσταση/αναβάθμιση του screen -> τα permissions έχουν γίνει reset στα αρχικά permissions του πακέτου
     

  Το dpkg παρέχει το dpkg-statoverride, που επιτρέπει την αλλαγή του owner/group και των permissions οποιουδήποτε αρχείου ενός πακέτου και τη διατήρησή τους σε μελλοντικές αναβαθμίσεις.

   

  - Το σύστημα των alternatives

  To debian έχει ένα ολόκληρο σύστημα, το οποίο επιτρέπει την system-wide επιλογή ενός προγράμματος από μια ομάδα προγραμμάτων που επιτελούν την ίδια λειτουργία, για να αντιστοιχίζεται ερήμην στη λειτουργία αυτή. Παραδείγματα είναι οι browsers, οι editors, κλπ. Το σύστημα των alternatives επιτρέπει μεταξύ άλλων να έχεις εγκατεστημένες περισσότερες εκδόσεις προγραμμάτων (π.χ. java5, java6, java-gcj) και να επιλέγεις κάθε φορά ποίο από αυτά θα ονομάζεται "java". Το Arch παρέχει κάτι αντίστοιχο μέσω μεταβλητών στο /etc/profile.d/. Ωστόσο, όπως μνημονεύει και το debian policy, αυτός είναι λάθος τρόπος, γιατί δε χρησιμοποιεί όλος ο κόσμος bash, ώστε να ισχύουν αυτά που έχει το /etc/profile.d/.

   

  [*] Build system

  - Στο arch linux ανεβαίνουν binaries στα repositories, τα οποία δεν είναι βέβαιο ότι έχουν προκύψει από το αντίστοιχο PKGBUILD. Επίσης, το ότι ανεβαίνουν binaries που έχει χτίσει ο κάθε developer στο σύστημά του, επιτρέπει μια «ελαστικότητα» ως προς τα δηλωμένα dependencies. Με λίγα λόγια, ο τάδε developer έφτιαξε το πακέτο, ξέχασε να δηλώσει τη libkokolala ως dependency, αλλά το πακέτο λειτούργησε κανονικά επειδή αυτή υπήρχε στο σύστημά του.

   

  Στο debian από την άλλη πλευρά, δεν ανεβαίνουν binaries, αλλά η περιγραφή του πακέτου, και το binary χτίζεται από τον build daemon μέσα σε ένα chroot που περιέχει μόνο τα δηλωμένα dependencies του control file. Επομένως για να πετύχει ένα build και να περάσει το πακέτο στο sid, πρέπει οι δηλωμένες εξαρτήσεις να είναι ακριβείς. Επιπλέον, η διανομή γίνεται αυτόματα build σε build farms, ώστε να ανιχνεύονται αυτόματα τυχόν ασυμβατότητες μεταξύ των πακέτων και των βιβλιοθηκών.

   

  Η τελευταία μέθοδος δεν είναι αποκλειστικότητα του debian φυσικά, αντίστοιχα πράγματα κάνει και το FreeBSD και διάφορες άλλες διανομές Linux, συμπεριλαμβανομένου και του Frugalware που χρησιμοποιεί τον pacman.

   

  - Το arch linux δε διαθέτει υπογεγραμμένα πακέτα, με αποτέλεσμα να πρέπει να εμπιστεύεσαι απόλυτα το mirror απ' το οποίο κάνεις sync.

   

  [*] Έλλειψη τεκμηρίωσης.

  - Το arch linux έχει ελλιπή τεκμηρίωση, η οποία εντοπίζεται στους

  παρακάτω τομείς.

  1. Δε συμπεριλαμβάνει το upstream documentation (README, ChangeLog, TODO), στερώντας από το χρήστη την πληροφορία που θέλουν να του δώσουν οι upstream developers.
     
  2. Δεν παρέχει καμία ένδειξη των τροποποιήσεων που έχουν γίνει στο πακέτο, ώστε να παίζει στη διανομή. Η μόνη λύση είναι να ψάξει κανείς στα άδυτα του SVN για να βρει logs της μιας γραμμής.
     

  Το Debian από την άλλη παρέχει στο /usr/share/doc/<package_name> όλο το σημαντικό upstream documentation, καθώς και τα αρχεία README.Debian και changelog.Debian που περιγράφουν τη σχέση του πακέτου με την υπόλοιπη διανομή καθώς και τις τροποποιήσεις που έχει κάνει το debian στο πακέτο (αν ρίξετε μια ματιά στο CVS του Arch Linux, θα δείτε ότι και εκεί υπάρχουν αρκετά patchαρισμένα πακέτα).

 

@flamelab: ακριβώς επειδή είμαι ο admin του συστήματός μου (και όχι μόνο), θέλω λοιπόν να μπορώ να αλλάζω permissions σε 1-2 πακέτα για να ταιριάζουν με το δικό μου setup χωρίς μετά να κάνει το PMS του κεφαλιού του, να χρησιμοποιώ zsh γιατί το βρίσκω καλύτερο για interactive χρήση χωρίς να σταματάνε να μου δουλεύουν τα μισά πράγματα που θεωρεί η διανομή ότι πρέπει να κάνει export ως environment variables, να εμπιστεύομαι ότι τα πακέτα που βάζω προέρχονται από εκεί που λένε και χρειάζονται όντως αυτά που λένε και να ξέρω τι θέλουν να μου πουν οι upstream developers για το software τους.

[firewalker]

Σε εμενα πως δεν το έκανε ποτε ; Tο "επικίνδυνα" δεν το καταλαβα. Ως επι το πλειστον είναι notifications αυτα με echos μεσα.

 

Υπήρχε πακέτο που έκανε ln -s libxxx.so.0 libxx.so.4 και μετά rm libxxx.so.3. Σαν dependency στο repo δεν υπήρχε αλλού. έλα όμως που είχα περασμένο πρόγραμμα που την ήθελε και κλώτσησε...

[teliparas]

Εδώ θα βρείς τις αρχιτεκτονικές που σε ενδιαφέρουν. Κατεβάζεις το install43.iso για την καθεμία.

Οπωσδήποτε διάβασε τα documents που θα βρείς εδώ και ξεκίνα την διαδικασία μόνο όταν είσαι 100% σίγουρος οτι κατάλαβες τι παίζει.

 

μια βοηθεια παρακαλω

κατεβαζω *bsd και bootarw κανονικα οταν ζηταω install σβηνει η λαμπα(=pc)

αυτο συμβενει και στο παλιο και στο νεο pc

[NullScan]

Εννοείς κάνει shutdown ή restart? Βγάζει κανένα μήνυμα πριν. Τι κοινό έχουν τα PC από θέμα hardware ή BIOS settings?

[teliparas]

Εννοείς κάνει shutdown ή restart? Βγάζει κανένα μήνυμα πριν. Τι κοινό έχουν τα PC από θέμα hardware ή BIOS settings?

 

hp ειναι και τα δυο

και κανουν shutdown