Závislost package managementu na skriptovacím jazyku (diskuse)

[R]

Slackware to ma pre zmenu v bashi a je to brutalne pomale.

[kuly]

Jo, každá sekunda se počítá.

[R]

So slabsim CPU trivialna operacia "removepkg" netrva sekundy, ale desiatky minut - staci mat nainstalovanych par balikov s vela subormi.

[Martin Matějek]

No nevím, nic takového jsem na mém Slackware (12.2) nezažil. Slabší CPU mám (PII 366 MHz), ale jediné co trvalo dlouho (ale ne desítky minut) bylo removepkg kernel-sources a kernel-modules. Co by to zrychlit mohlo by asi byl "tichý" režim, kdy by se nezobrazovaly hlášky "Deleting --> /neco/nekde/..." pro každý soubor. Každopádně mi to nepřijde nijak přehnaně pomalé.

[kuly]

Souhlasim, ze u removepkg se ten overhead vyrazne nascita, ale na jedne 486ce jsem postupne pouzival slacky od verze 3 do 10 a desitky minut jsem nezaznamenal.

[SPM]

Gentoo má taky pythonní a asi by se našly i další... holt je potřeba si dávat pozor :)

[Marián Kyral]

Gentoo má ještě Paludis (C++). Ale zatím jsem necítil potřebu migrovat, tak zůstávám u "pomalého" emerge.

[SPM]

Měl jsem, někde i ještě používám, ale zase mi přijde, že s některým bordelem v portagi se to oproti emerge vyrovnává o dost hůř...

[David Watzke]

Ano, to je účel. On ti pomůže ten bordel odstranit a znovu ho tam nedostat.

[vlastikroot]

Když se člověku rozsype kernel, nebo si nainstaluje nekompatibilní verzi, pak nefunguje správa balíků

[Kvakor]

Udržovat více různých jader je oproti udržování více verzi knihoven a balíčkovacích managerů velmi jednoduché, stačí jen zajistit, aby se nové jádro jinak jmenovalo (přes localversion) a navzájem se nepomíchali moduly.

[Shadow]

Až na výkon (rychlost, efektivita využití paměti) v tom nevidím problém - uživatel by neměl nahrazovat distribuční interpret jinou verzí (a pokud to udělá, je za následky zodpovědný sám) a správci distribucí by měli dohlížet na to, aby se do repozitářů nedostaly nekompatibilní verze interpretu.

A proč to nikdo nepřepsal do C/C++? Možná proto, že v těch skriptovacích jazycích se to prostě psalo postatně rychleji, snadněji a "bezpečněji", tj. nikomu se to nechtělo dělat v Céčku. Možná se také uvažovalo o tom, že s použitím interpretovaných jazyků bude snadnější rozšiřovat funkcionalitu (či opravovat chyby) daných nástrojů, popřípadě že bude pro administrátory snadnější provádění případných úprav.

Samozřejmě bych tímto svým názorem nerad odradil případné dobrovolníky, kteří se do přepsání existujících a funkčních nástrojů do C/C++ pustí.

[Ruža Becelin]

Krome YUM jeste cela Anaconda + vsechny utility od RedHatu vcetne GUI jsou psane v Pythonu. Ne, ze bych z toho mel radost, ale tak to momentalne je...

[michich]

Pokud nějak rozbiješ yum, můžeš to zachránit na nižší úrovni (rpm).

[kavol]

... a když si rozbije rpm, tak to může zachránit busyboxem

[Grunt]

Tak nepovýší svoji distribuci na nejnovější verzi standardním způsobem, ale pomocí yum update (a přitom rozbije půlku systému):

$ preupgrade
/usr/lib/python2.6/site-packages/yum/__init__.py:203: UserWarning: Use .preconf instead of passing args to _getConfig
  warnings.warn('Use .preconf instead of passing args to _getConfig')
Loaded plugins: blacklist, refresh-packagekit, whiteout
Detected in-progress upgrade to Fedora 12 (Constantine)
Clearing data from upgrade to Fedora 12 (Constantine)
preupgrade (baseurl) 
  url: http://fake.url/preupgrade
  now: http://fake.url/preupgrade
preupgrade-chromium (baseurl) 
  url: http://fake.url/preupgrade-chromium
  now: http://fake.url/preupgrade-chromium
preupgrade-main (mirrorlist) 
  url: http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-12&arch=$basearch
  now: http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-12&arch=x86_64
preupgrade (mirrorlist) 
  url: http://mirrors.fedoraproject.org/mirrorlist?path=pub/fedora/linux/releases/12/Fedora/$basearch/os
  now: http://mirrors.fedoraproject.org/mirrorlist?path=pub/fedora/linux/releases/12/Fedora/x86_64/os
preupgrade-chromium (baseurl) 
  url: http://spot.fedorapeople.org/chromium/F12/
  now: http://spot.fedorapeople.org/chromium/F12/
preupgrade-fedora (mirrorlist) 
  url: https://mirrors.fedoraproject.org/metalink?repo=fedora-12&arch=x86_64
  now: https://mirrors.fedoraproject.org/metalink?repo=fedora-12&arch=x86_64
unknown metadata being downloaded: metalink
preupgrade-fedora-source (mirrorlist) 
  url: https://mirrors.fedoraproject.org/metalink?repo=fedora-source-12&arch=x86_64
  now: https://mirrors.fedoraproject.org/metalink?repo=fedora-source-12&arch=x86_64
preupgrade-rpmfusion-free (mirrorlist) 
  url: http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-12&arch=x86_64
  now: http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-12&arch=x86_64
preupgrade-rpmfusion-free-source (mirrorlist) 
  url: http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-source-12&arch=x86_64
  now: http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-source-12&arch=x86_64
preupgrade-rpmfusion-free-updates (mirrorlist) 
  url: http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-updates-released-12&arch=x86_64
  now: http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-updates-released-12&arch=x86_64
preupgrade-rpmfusion-free-updates-source (mirrorlist) 
  url: http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-updates-released-source-12&arch=x86_64
  now: http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-updates-released-source-12&arch=x86_64
preupgrade-rpmfusion-nonfree (mirrorlist) 
  url: http://mirrors.rpmfusion.org/mirrorlist?repo=nonfree-fedora-12&arch=x86_64
  now: http://mirrors.rpmfusion.org/mirrorlist?repo=nonfree-fedora-12&arch=x86_64
preupgrade-rpmfusion-nonfree-updates (mirrorlist) 
  url: http://mirrors.rpmfusion.org/mirrorlist?repo=nonfree-fedora-updates-released-12&arch=x86_64
  now: http://mirrors.rpmfusion.org/mirrorlist?repo=nonfree-fedora-updates-released-12&arch=x86_64
preupgrade-updates (mirrorlist) 
  url: https://mirrors.fedoraproject.org/metalink?repo=updates-released-f12&arch=x86_64
  now: https://mirrors.fedoraproject.org/metalink?repo=updates-released-f12&arch=x86_64
unknown metadata being downloaded: metalink
preupgrade-updates-source (mirrorlist) 
  url: https://mirrors.fedoraproject.org/metalink?repo=updates-released-source-f12&arch=x86_64
  now: https://mirrors.fedoraproject.org/metalink?repo=updates-released-source-f12&arch=x86_64
preupgrade-updates-testing (mirrorlist) 
  url: https://mirrors.fedoraproject.org/metalink?repo=updates-testing-f12&arch=x86_64
  now: https://mirrors.fedoraproject.org/metalink?repo=updates-testing-f12&arch=x86_64
Traceback (most recent call last):
  File "/usr/share/preupgrade/preupgrade-gtk.py", line 240, in on_assistant_apply
    self._do_main()
  File "/usr/share/preupgrade/preupgrade-gtk.py", line 259, in _do_main
    self.main_preupgrade()
  File "/usr/share/preupgrade/preupgrade-gtk.py", line 436, in main_preupgrade
    download_progressbar=self.dnlProgress)
  File "/usr/lib/python2.6/site-packages/preupgrade/__init__.py", line 130, in setup
    self.complete_repo_setup()
  File "/usr/lib/python2.6/site-packages/preupgrade/__init__.py", line 328, in complete_repo_setup
    repo._grabfunc.opts.user_agent = __user_agent__
AttributeError: 'NoneType' object has no attribute 'opts'

[michich]

$ preupgrade
[...]
  File "/usr/lib/python2.6/site-packages/preupgrade/__init__.py", line 328, in complete_repo_setup
    repo._grabfunc.opts.user_agent = __user_agent__
AttributeError: 'NoneType' object has no attribute 'opts'

To je RHBZ#538118, mělo by být opraveno v preupgrade-1.1.4.

[Conyx]

No a co? U binarniho package manageru by sis zase mohl pos*** X knihoven na kterych je zavisly a prestal by ti slapat.

[Grunt]

K tomu se musím přidat. Knihovy na kterých ten balíčkovací systém závisí se mění docela často (snad i častěji než ten Python). Sice jsem nezažil, že by se to kvůli tomu někdy rozbilo (ťuk, ťuk), ale nebezpečí je minimálně ekvivalentí a u toho Pythonu nebo Perlu to jde ještě relativně snadno s malou pomocí Googlu a jazyka spravit. Aby ta binární verze byla super-bezpečná, tak by musel být staticky slinkovaná.

[Grunt]

A to jsem ještě zapomněl na nějaké interní databázové techtle-mechtle (už se mi párkrát stalo i s tím binárním aptem nebo na kýho šlaka je to ještě nalinkované). To už je pravděpodobnější.

[Jakub Lucký]

Pak se to řeší tak, že člověk najede na packages.distribuce.tld, tam si stáhne starou verzi a přeplácne ji pomocí low-level pakážovacího software, který obvykle v C/C++ je (dpkg, rpm)

[pozortucnak]

Není pacman napsaný náhodou v C?

[l4m4]

Jelikož rpm není napsáno ve skriptovacím jazyce, není pravda, že package management Fedory či Mandrivy je napsán ve skriptovacím jazyce. Takže zbytek zápisku jsou kydy.

[pozortucnak]

A programy instaluješ jak? Pomocí rpm -i ?

[l4m4]

Ne, pomocí rpm -Uvh [--oldpackage] [--replacepkgs] [--replacefiles]. Když je to zapotřebí. Když není, tak samozřejmě klidně použiji nějaký frontend.

yum ve Fedoře je teprve šest let stará věc, to jsi tak zapomnětlivý, nebo takový zelenáč?

[pozortucnak]

Já mám jakousi averzi k rpm... je jich nějak moc, Mandriva Suse Fedora PClinuxOS... a univerzálních rpm moc není...
Nějakou dobu jsem používal Debian, ale pomalost balíkovacího systému a ty šílené konfigurační perl scripty mě donutili přejít k Archlinuxu...

[l4m4]

Navíc instalace není jediná věc, kterou člověk se software dělá. Např. rpm --verify mi přijde podstatně jednodušší než instalace yum-plugin-verify a používání yum verify, který oproti rpm neumí nic navíc. Jednotlivé balíky mažu téměř výhradně rpm -e, protože je to jednodušší.

[Ondřej Kubečka]

OpenSolaris oproti Solarisu mimo jiné přichází s novým systémem balíčků... v Pythonu. Takže asi popisujete obecnější tendenci světa.

[vogo]

Balíčkovací manager napsaný v C není samospásný, viz:

$ pacman -Qii pacman
Jméno          : pacman
Verze          : 3.3.3-1
URL            : http://www.archlinux.org/pacman/
Licence        : GPL
Skupiny        : base
Poskytuje      : Nic
Závisí na      : bash  libarchive>=2.7.1  libfetch>=2.25  pacman-mirrorlist
Volitelné záv. : fakeroot: for makepkg usage as normal user
                 python: for rankmirrors script usage
Požadovaný     : pacman-color  yaourt
Konfliktní s   : Nic
Nahrazuje      : Nic
Vel. instalace : 2244,00 K
Zabalil        : Dan McGee <dan@archlinux.org>
Architektura   : x86_64
Datum sestavení: St 11. listopad 2009, 00:58:30 CET
Datum instalace: Út 1. prosinec 2009, 20:46:54 CET
Důvod instalace: Výslovně nainstalován
Instal. skript : Ano
Popis          : A library-based package manager with dependency support

v závislostech jsou knihovny libarchive a libfetch a navíc pacman sám osobě mí libalpm, pokud se něco nepovede a knihovny nebudou, nebo budou v nekompatibilní verzi, jsi v kelu stejně jako se skriptovaným správcem balíčků... Pravda existuje způsob jak z toho ven - staticky likovaný pacman - ale kdo ho má? Už dávno není v balíčku s pacmanem... V Archu je ještě možnost z toho vybruslit ručním rozbalením balíčku a nakopírováním patřičných souborů na patřičná umístění... nebo použít pacmana z jiné fungující instalace pomocí přepínače --root

[Käyttäjä 11133]

A nebo si tu statuicky linkovanou binárku vyrobit :)

[pozortucnak]

[all@myhost Downloads]$ tupac -Ss pacman | sed 'N;s/\n//g' | grep -i static
46 archlinuxfr/pacman-static 3.2.2-1    Static version of pacman executable
76 aur/pacman-static 3.2.2-1 (6 votes)    Static version of pacman executable

[vogo]

celkem obsolete, když máme verzi 3.3.3

[maertien]

Vsechno by to melo byt v tcl. To by bylo bezpecne.

[pozortucnak]

Tcl vyšel z módy...

[Rezza]

To je duvod, proc se napr. ve Fedora snazi psat u Pythonich skriptu cela cesta k Pythonu, kdyby si nekdo rozmyslel pouzivat jinou a pak ji mel v PATH na prvnim miste. Ale co je v repozitari, tak by vetsinou melo pasovat k sobe (jen se hur resi problemy ala zmena v Pythonu, knihovnach - pac to nezarve pri rebuildu jako u prekladanych veci).

[sxznam]

Z toho duvodu koukam napsali v Novellu YUM-compatible front-end na zelené louce a v C++ (zypper)