Joskus menneinä aikoina Portage rouskutteli hyvän aikaa ennenkuin mitään alkoi tapahtua ja pakettien tauhkatkin piti hakea erikseen ennenkuin pistettiin ramppa kalkattamaan. Siitä huolimatta nuo vaihtoehtoiset toteutukset eivät ole juuri muuta kuin sivumaininta historiassa, jos sitäkään.
Muistelen, että silloin Portage ei osannut ainakaan vakiona hakea taustalla vaan piti käynnistää toinen instanssi hakemaan paketit ilman kääntämistä. Tuolla oli iso vaikutus hitaalla yhteydellä jos paketteja ei ollut ladannut ennakkoon ja käänsi koko systeemin. Configure cachella oli myös iso vaikutus, maken optimaalinen rinnakkaisuus oli jotain nprocin ja 2*nprocin välillä (jos omisti tuplaytimen / p4 ht:llä). Muistaakseni ebuildien säilöminen fragmentoitumattomaan reiser3-voluumiin myös säästi selvästi aikaa. Emergen c-porttaus oli myös selvästi nopeampi (en muista nyt nimeä). Sittemmin Gentoon riippuvuuksien hallinta on minusta monimutkaistunut. Toisaalta Python nopeutunut.
Alun dependencyjen resolvaamisen ja buildijärjestyksen hiomisen jälkeen Portagelle jää suht vähän tekemistä, fetch pyörii taustalla taustalla samalla kun paketit kääntyy eikä tuotosten siirtäminen hiekkalaatikolta järjestelmään kovin raskasta ole. Python-toteutus ei ole vuosikausiin ollut pullonkaulana näissä, itse kääntämiseen Portagen nyplääminen ei oikein auta ja siihen se aika tuppaa palamaan.
On sillä se merkitys, että joka paketin välissä perusjauhaminen voi kestää vaikka sekunnin tai kaksi kauemmin (*) ja sitä kautta esim. 3000 paketin tapauksessa voi tulla tunti lisäaikaa. Mutta siis aika ääritapauksesta on kyse. Toki noissa rolling-distroissa helposti tulee paljon asennettavaa, jos on hetken aikaa päivittämättä.
(*) jälleen esimerkki 20 vuoden takaa. Nyt Python + uusi kone voi toimia nopeammin.
No eihän se nyt ole ollenkaan näin. Paketti manageri joka tsekkaa riippuuvuuksia on aina moninkerroin hitaampi kuin sellainen joka ei tsekkaa oikeastaan mitään vaan asentaa paketin joka sille käsketään asentamaan.
Pacman katsoo kyllä aina että riippuvuudet löytyvät. Siinä on vaan paljon kevyempi tuo metadata, niin menee paljon nopeammin. En sano että tämä on parempi asia, mutta nopeampi takuulla.
Joku 500 pakettia kun asennetaan niin se metadata kolutaan kerran jonka jälkeen vaan asennetaan jolloin suhteellinen nopeus on moninkertainen verrattuna siihen että ne samat 500 pakettia asennettaisiin yksi kerrallaan joka ikinen kerta metadata tsekaten.
Jos paketinhallinnassa on mallinnettu monimutkaisia versioriippuvuuksia esim. epäyhtälöillä tai use-flageja, niin tuosta tulee monella paketilla matemaattisesti paljon hankalampi ongelma, kun pitää löytää sellainen kombo paketteja, joka suostuu asentumaan ja mahdollisesti pakittaa ja etsiä uusi kombo vipuja, joilla kääntyy.
No itsehän sinä tuon testin toit mukaan keskusteluun. Jos se on huono, niin miksi sen sitten sotkit tähän? Ja minä kuitenkin sinulle kerroin että testin tein selvästi HEIKOMMALLA koneella mitä orkkis testi oli tehty ja vertasin dnf4 <-> dnf5. EN ottanut mitään kantaa siihen että miten vertautuu vaikka apt.
Se on huono esimerkki, mutta artikkelin tekijä oli tehnyt kotiläksyt ja verrannut itse ja julkaissut datan. Jos 2019 kesti Fedoralla 25 sekuntia ja nyt sinulla reilu 6 sekuntia, niin on ihan mahdoton tietää, johtuuko se koneiden nopeutumisesta vai pakettimanagerin. Tarkoitan vaan että tuo yksi datapiste ei auta.
Huoh... on kait se kun vertaat omenoita mansikoihin. dnf tekee aika helvetin paljon muutakin kuin purkaa locaalin paketin joka tuossa sun esiamerkissä noin karkeasti tapahtui.
Ymmärrätkö etten pysty tekemään vastaavaa esimerkkiä perustamatta omaa pacman-mirroria, kun ko. pakettia ei saa ilman manuaalista kääntämistä asennettua ko. distroon? Tuossa kääntämisessä menee täällä 35 sekuntia. Koitin jo sanoa, että tuo on todella huono esimerkki, kun se pakottaa yhden suosituimmista distroista kääntämään paketin virallisten repojen ulkopuolelta. Tässä olisi nopeasti helppo listata vaikka 2000 muuta pakettia, jotka löytyvät top10 distroista vakiona.
Koodi:
time rpm -U --noverify --nodeps ack-3.7.0-7.fc42.noarch.rpm
real 0m1.447s
user 0m1.109s
sys 0m0.232s
Toi vois olla aika lähellä tuota sun juttuas. Tuossa siis ack ladattu ensin ja sitten asennus suoraan rpm:llä.
Kun ei ole. Pacman ei asenna edes lokaalisti paketteja, jos riippuvuudet menevät rikki. Jos riippuvuudet löytyvät netistä, niin se tarjoutuu asentamaan, mutta jos ei löydy (esim. AUR-paketti), niin asennus epäonnistuu. Asennus myös vertaa esim. tiedostolistoja ja tietenkin paketin integriteetin ongelma voidaan huomata. Otan nyt tuon esimerkin ajon tilanteessa, kun perl-file-next puuttuu:
Koodi:
$ sudo pacman -U ack-3.8.2-1-any.pkg.tar.zst
ladataan paketteja...
selvitetään riippuvuuksia...
varoitus: pakettia 'perl-file-next' ei voida selvittää; se on paketin 'ack' riippuvuus
:: Seuraavaa pakettia ei voida päivittää selvittämättömien riippuvuuksien vuoksi:
ack
:: Haluatko ohittaa yllä olevan paketin päivittämisen? [k/E]
edit: Se mitä tuossa jää pois on sha256-summien tarkistus. Senkin voi erikseen tehdä käskyllä 'paccheck --sha256sum' asennetuille paketeille. En nyt heti löytänyt, saisiko sen -U -käskyllä vakiona päälle. Tässä omalla koneella tuon ack-paketin osalta sen sha256-tarkistus kestää 0,012s eli tuo yhteisaika kasvaa noin 260 millisekuntiin. Testasin myös ihan huvikseni lisäämällä/poistamalla manuaalisesti paketista tiedostoja ja tämä tuli esiin asennettaessa. Paccheck huomasi kun korruptoin paketin binäärin.