Erot pakettien hallinnassa Debianin ja Archin välillä

Käytän archia vain säännöllisesti muutaman viikon ajan enkä ole aiheen asiantuntija, joten tämä vastaus ei suinkaan ole tyhjentävä, vain muutama huomautus, jonka olen huomannut ”joustavuudesta / voimasta”:

• Tämä on vain vaikutelma, mutta pacman näyttää nykyaikaisemmalta ja yksinkertaisemmalta suunnittelussaan / arkkitehtuurissaan. Ainakin työkaluja on paljon vähemmän käsitellä. Vaikka en tiedä apt-lähdekoodia, sattuin vain katsomaan libalpm-koodia (Pacmanin taustalla olevaa kirjastoa) saadaksesi hyvin yksinkertaisen korjaustiedoston, ja se näyttää puhtaalta ja helposti ymmärrettävältä.

• Se on myös erittäin nopea (optimoinnin takia ja todennäköisesti myös huolehtimalla muutamista asioista (katso alla)). Viimeinen julkaisu (muutama päivä vanha pacman 3.5) yritti parantaa suorituskykyä vähentämällä mukana olevat tietokantatiedostot.

• Vaikka arch on suuntautunut binaaripakettien käyttöön, sillä on myös etuja, kun rakennetaan paketteja lähteestä, BSD: n porttien kaltaisella koontijärjestelmällä ( ABS).

• Pakettien luominen on erittäin helppoa ja nopeaa, vain muutama rivi PKGBUILD-tiedostossa ja se on tehty. Ohjausta / sääntöjä / tekijänoikeuksia ei tarvitse käsitellä / changelog / mitä tahansa Debian-pakettien kanssa. Ja muutamalla napsautuksella web-käyttöliittymässä pakettisi jaetaan kaikille AUR: n (Arch-käyttäjärekisteri) käyttäjille.

Saan asioita Debianissa eikä arkistossa:

• Käynnistimet / h ooks (mikä saa apt: n päivittämään kuvakevälimuistin, mandb: n tai minkä tahansa vain katsomalla, mihin paketti asentaa tiedostot, ilman että pakettia tarvitsee tehdä mitään) (näyttää siltä, että aikoo toteuttaa tämän).

• debconf (ei iso juttu ja muuten pakottamalla minut tekemään asioita manuaalisesti, se pakottaa minut tietämään, mitä tarkalleen tehdään) ja uusien asetustiedostojen asianmukainen käsittely (haluaisin ainakin pacmanin tietävän, milloin uuden pakettiversioissa oleva konfigurointitiedosto eroaa asennetusta tiedostosta, koska sitä muutettiin uudessa versiossa tai koska muokkain sitä paikallisesti).

• paketin allekirjoittaminen (näyttää siltä, että sen kanssa toimi ).

Koska kaari on kevyt, ainoa todellinen syy on, että siihen sisältyy muutama paketti oletusarvoisesti, ja sinua kannustetaan lisäämään tarvitsemasi, joten luultavasti ei valinnaisten riippuvuuksien asentaminen oletuksena kannustaa käyttäjiä asentamaan välttämään turvotusta .

Kommentit

• En voi ’ t jäsentää tätä: mutta voin tehdä ilman sitä ja muuten tietää, mitä teen paremmin . Viimeisessä lauseessa on myös kirjoitusvirhe.
• Millä kielellä Pacman-paketinhallinta on kirjoitettu? Onko sillä matalan ja korkean tason paketinhallintatoimintoja, jotka ovat samanlaisia kuin dpkg / apt, ja jos on, niin mitä heille kutsutaan?
• @Tshepang: anteeksi, täällä ei ole äidinkielenään äidinkielenään puhuvia. Tarkoitin ” tämä ei ole minulle iso ongelma, koska minulla ei ole tätä toiminnallisuutta (debconf), ja pakottamalla minut tekemään asioita manuaalisesti se pakottaa minut tietämään mitä tarkalleen tehdään ”.
• @Faheem Mitha: Pacman on kirjoitettu C-kirjaimella ja on libalpmin käyttöliittymä, joka käsittelee molempia ” korkeita -taso ” ja ” matalan tason ” paketin hallinta.
• @zanko: En ’ ole myöskään äidinkielenään puhuva. Halusin sinun tekevän vain selkeämmän lauseen, ei kommentissa, vaan itse viestissä. BTW, kirjoitusvirhe, jonka mainitsin, on vaihtoehtoinen . Voisin muokata viestiä itse, mutta ajattelin, että voisit myös korjata sen yhdessä selvennysosan kanssa.

Aloitin Linux-matkan Ubuntu lucidilla ja käytän tällä hetkellä Archia.Olen kirjoittanut kourallisen Arch-paketteja, ja sanon sen paljon helpommaksi kuin Debian-pakettien kirjoittaminen. Mutta haluaisin huomauttaa @gentledevil , että Archilla on pakettien koukkujärjestelmä, joka tunnetaan nimellä install file.

Pohjimmiltaan sen nimi on ${pkgname}.install, ja se sisältää muutamia toimintoja asennusta edeltävälle / jälkeiselle / poistamiselle / päivittämiselle; aseta vain fontti-välimuistipäivitykset siinä ja niin edelleen, ja se toimii suunnilleen samalla tavalla kuin Debianin koukut.

Huomaa myös, että mainitsit sovelluksen ”kiinnittämisen” käyttämällä Debianin paketinhallintatyökaluja; Archin pacmanilla on sisäänrakennettu samoin /etc/pacman.conf hyväksyy useita asetuksia, mukaan lukien IgnorePkg =, jotka estävät päivitykset mihin tahansa pakettiin, joka on lueteltu yhtälön (välilyönti erotettu) jälkeen )

Kommentit

• Vaikka se ei ole repo-paketti, voit myös käyttää powerpill -kääriä jotta pacman voi ladata samanaikaisesti useita paketteja, joten sen sijaan, että pacman -S libfoo libbar libbaz lataaisi kukin paketti yksi toisensa jälkeen r sen sijaan lataa kaikki kolme samanaikaisesti, mikä lisää huomattavasti päivitysnopeutta parempien yhteyksien saamiseksi.

Ennen kuin minä mene liian pitkälle, tutustu kuvamaiseen Linux-aikajanaan

Jotta ymmärtäisit pakettien hallinnan eroja, sinun on ymmärrettävä käyttöjärjestelmän filosofiat ” Yllä olevat kuvat

Kolme suurta vanhempaa

1. Redhat, Now Fedora – Package Manger – RPM, lyhenne sanoista Redhat Package Manager, komentorivi rpm
2. Slackware – Package Manager – tgz, tavalliset pakatut tiedostot. Vaikka nämä ovat vain pakattuja tiedostoja, Slackware on rakentanut ne ylävirtaan ja sijoittanut tietovarastoon, jota kutsutaan joskus portiksi.
3. Debian – DEB, lyhenne sanoista Debian, sen komentorivityökalu on Aptitude or Apt

Nämä vanhemmat ovat äitejä ja isiä suurimmalle osalle nykyisistä jakeluista. Pakettien hallintajärjestelmän idea / käsite on johdettu tai jaettu joissakin muoto tai muoti. Siitä huolimatta, kaikki nämä vanhemmat ovat binaarijakelijoita, mikä tarkoittaa, että kolmas osapuoli pakkaa ja päättää ohjelman, tallentaa sen sitten arkistoon ja käyttäjäkunta kuluttaa tai asentaa.

3 Alaikäiset vanhemmat

1. Linux From Scratch – lähdepohjainen, ei pakettien hallintaa.
2. Gentoo – johdettu Linuxista Scratch . Tämä jakelu on lähinnä Linuxia Scratchista sekä paketinhallinnasta, nimeltään Portage / emerge
3. SourceMage – Package Manager Sorcery

Nämä vanhemmat ovat pieniä, koska heidän käyttäjäkuntansakäy kauppaa nopeudella ja helpolla asennuksella teholla ja helpolla konfiguroinnilla. Jokainen paketti ladataan ja käännetään alusta alkaen muuttujien ja määritystiedostojen avulla.

Silta

Kaari luotiin siltana binaarijakauman välillä, kuten yksi kolmesta suuremmasta vanhemmasta, ja lähdepohjainen jakelu kuten yksi kolmesta alaikäisestä vanhemmasta. Sellaisena se saa vanhemman tilan aikajanalla, koska kukaan muu vanhempi ei tarjonnut tätä toimintoa. Pacman voi joustavasti sallia käyttäjän asentaa binaaripaketin virallisesta arkistosta tai mukautetun paketin käyttämällä Arch Build System -järjestelmää. Tämä käsite tarjoaa tasapainon alaikäisten vanhempien antaman voiman ja isojen vanhempien antaman asennuksen helppouden välillä.

Mielestäni paketinhallinta ei osoita järjestelmää, koska kaikki paketinhallintaohjelmat tekevät saman tehtävän, joka on terveellisen järjestelmän hallinta ja ylläpito. Sellaisena käyttämäsi järjestelmä tulisi määrittää seuraavien tekijöiden avulla:

• Käyttäjätaso: Joku uuden Linux-käyttöjärjestelmän pitäisi alkaa suuremmalla vanhemmalla, kun taas joku teknisesti osaava löytää tasapainon.
• Mitä haluat tehdä järjestelmälläsi: LAMP-palvelimen suorittaminen liitettyjen käyttäjien kanssa on täysin erilaista kuin pöytätietokoneen käyttö. verkkoselaamiseen ja sähköpostin lukemiseen.
• Mukavuustaso: Käyttäjätaso ei kestä, jos olet teknisesti taitava, mutta et halua viettää viikonloppua järjestelmän kokoamisessa, valitset isovanhemman, riippumatta siitä, valitsevatko kaikki tuntemasi henkilöt jotain muuta.

Kommentit

• Tämä on enemmän fokusta käytetään jakelujen geneaologiassa eikä Pacmanin ja Debianin ’ paketinhallintatyökalujen vertailun sijasta …
• @jasonwryan That ’ s asia, koska kaikki paketinhallintaohjelmat suorittavat saman tehtävän, eli emerge packagename on sama kuin sudo apt-get install packagename.
• Tällä tasolla kyllä; mutta siitä puuttuu täysin kysymyksen asia, ts. mikä erottaa pacmanin {apt, aptitude} -ominaisuudesta.
• @jasonwryan Vastasin siihen The Bridge -osiossa. Muuten ei ole eroa. Ainoat erot ovat semanttisia, toisin sanoen yksi komento toiseen.Jos OP etsii semanttisia eroja, siihen on olemassa käsikirja.

Tämän on kirjoittanut ei tarkoita täydellistä tai tyhjentävää vastausta – ennen minua olevat julisteet antoivat jo joitakin erittäin hyviä pisteitä, haluaisin vain lisätä 2 senttiäni. Toinen asia – en ole koskaan tottunut apt / dpkg: hen. Se tuntui aina liian monimutkaiselta minä, olen todella mukavin yum / rpm: n kanssa.

pacman on erittäin helppokäyttöinen, mikä on ammattilainen ja huijaus – voit oppia käyttämään sitä (paketin rakentaminen sivuun) yhden iltapäivän aikana – se käyttää enimmäkseen intuitiivisia ja täydellisiä paketinhallintaominaisuuksia, mutta – ja tämä on iso mutta – se on erittäin joustamaton.

Jos suunnittelijat eivät ajatelleet ominaisuutta etukäteen, olet väärässä.

Muutama esimerkki: pacmanissa ei ole natiiviversiota. Jos haluat päivittää pakettiversiota, sinun on ladattava kyseinen pakettiversio ja asennettava tiedostosta -U (päivitys) -vaihtoehdolla. on hyvin suunnattu alwaan ys käyttämällä huippuluokan paketteja järjestelmässäsi.

Todellista sisäistä välimuistin puhdistusta / täydellistä uudelleenrakentamista ei ole. Jos (verkko-ongelmasta johtuen) paketin lataus vioittui, esim. -Syu aikana, virheilmoituksesta ei ole paljon hyötyä, vaikka se on tarkka – siitä ei löydy vioittunutta pakettia edes ”täyden” sanattomuuden ja virheenkorjauksen ollessa päällä , eikä mikään -Syyc-määrä puhdista välimuistia ja lataa paketteja uudelleen. Hyvä uutinen on, että -Sc ilmoittaa sinulle, missä ladatut paketit ovat, joten voit yksinkertaisesti poistaa loukkaavan (jos pystyt selvittämään mikä on) tai kaikki niistä ja käynnistämään -Syu uudelleen.

pacman-integrointi dkms: n kanssa on myös jonkin verran ongelmallista – asennettaessa uutta ydintä minulla oli edelleen virheitä dkms: stä. Käyttämällä dkms build & & dkms installia uudelle ytimelle, joka toimi ongelmitta, mutta pacman ei tarjoa mitään tietoa miksi dkms epäonnistui ytimen päivitys (epäilen, että se ei koskaan läpäissyt uuden ytimen oikeaa polkua, ja anna dkms: n käyttää vain oletus (nykyinen käynnissä) ydintä, mutta väärällä versiolla).

Toinen anekdootti siitä joustamaton totesi, olen tottunut kierrosta / vuosi. Jos järjestelmässäni on tiedosto ja haluan tietää, mikä paketti omistaa sen, voin suorittaa yum provides / path / to / file ja saada KAIKKI paketit, jotka voivat laittaa sen sinne – vaikka mikään niistä ei olisi asennettu. Jos tiedosto on sijoitettu manuaalisesti ja nyt haluan asentaa paketin – se nimeää uuden uudelleen (lisää laajennus .rpmnew) ja antaa minun valita, mitä käyttää.

pacman yksinkertaisesti erehdyttää tiedoston jo on olemassa, mutta täysin epäolennaisella virheilmoituksella – se valittaa tiedoston ”todellisen” omistajan ja tällä hetkellä asennetun ”filesystems” -paketin välisestä ristiriidasta, ikään kuin se olisi myös saman tiedoston omistaja. Lisäksi se on suunnattu lähinnä paikallisiin asennettuihin tietoihin – tiedon hankkiminen (kuten tiedostoluettelot ja omistajuus) paketeista, joita ei ole vielä asennettu, on vähemmän intuitiivista.

Yksinkertaisesti sanottuna – se ei ole yhtä kypsä kuin yum, ja luultavasti dpkg, joka antaa sille myös helppokäyttöisyytensä, on suhteellinen joustamattomuus.

Kommentit

• Lyhyt, kattava vastaamatta jättäminen, on useita esille nostamiasi kohtia, jotka todella ovat tuntematon Pacmanin kanssa. Esimerkiksi pacman -Qo $file kertoo, mikä paketti omistaa $ -tiedoston. Koko vastauksesi on myös olkamies, koska OP pyysi nimenomaisesti eroja Archin ja Debianin välillä – yum ei ole mitään tekemistä sen kanssa …
• minkä vuoksi paljastin nimenomaisesti tuon tosiasian vastaukseni alussa. Mitä tulee tiedostoon -Qo $ – oletko koskaan kokeillut sitä paketille, jota ei ole vielä asennettu?
• Ei ole mitään järkeä kokeilla sitä asentamattomalla paketilla; siihen on muita työkaluja. Ja paljastaminen ei ’ t lievennä sitä tosiasiaa, että et ole ’ vastannut kysymykseen: a ” yum ja pacman välinen vertailu ” ei ole sama kuin Debianin ’ s ja Archin erot ’ n pakettien hallinta.
• @jasonwryan Tietysti on asia. Vain siksi, että et ’ näe tarvetta selvittää, mikä paketti saattaa omistaa tiedoston, vaikka sitä ’ ei ole vielä asennettu, ei ’ t tarkoittaa, että tällaista tarvetta ei ole ’. Se oli asia. Mitä tulee muihin työkaluihin – ovatko ne tarpeen tietää? pacman on paketinhallinta. Mitä tulee pääkohteeseesi – olen ehkä lukenut kysymyksen täysin väärin, mutta oletin, että kyse on kevyestä PM: stä monimutkaisemmasta PM: stä. Oletan, että apt / dpkg on vähintään yhtä monimutkainen kuin yum / rpm, ominaisuus viisasta.
• Tarkoitan, että vastaat kysymykseen omenoiden ja appelsiinien vertailusta vertaamalla rajoitettua ymmärrystäsi omenoista päärynöisiin. Ja kyllä, olet lukenut kysymyksen täysin väärin …