FreeBSD lokális repó használata

Van pár olyan szoftver a ports-ban, ami bináris csomagból nem érhető el (pl. licencprobléma miatt), ehhez jöhet jól. (Nálam pl. lame, meg a faac, stb.)

A parancsokat gyakorlatilag mind root-jogal kell futtatni, speciális beállítások esetén kb a make all az egyetlen, amit lehet normál felhasználóként (ezt jelzi a prompt)

Előkészítés, lokális csomag előállítása és megfelelő helyre rakása:

# mkdir -p /usr/ports/packages/All
# cd /usr/ports/audio/lame
# make all package
# mv work/pkg/lame-3.99.5_1.txz /usr/ports/packages/All/
# make clean

(Van olyan gépem???? amin van PACKAGES make-változó - /usr/ports/packages értékkel -, ekkor eleve megfelelő helyre került a csomag, és van olyan, ahol nincs ez a változó, ekkor kell a mv.)


Jav. 2014.12.15:

(Most egy másik gépen futtattam make package-et, annyit látok, hogy ha nincsen meg valami miatt a /usr/ports/packages könyvtár, akkor a make package azt nem csinálja meg, hanem az eredmény a work/pkg -ban marad. Ha van /usr/ports/packages (vagy nyilván ami meg van adva a PACKAGES változóban), akkor ha kell, az All alkönyvtárat megcsinálja, és odamásolja a kész csomagot - work/pkg-ban ekkor is megtalálható marad. - Jelzem, ez a make ports-ban le is van írva. Elképzelhető, hogy amikor eredetileg írtam és próbáltam, a teszgépen sem volt meg ez a könyvtár.)

Természetesen valahányszor az adott csomag frissül, a könyvtárba fel kell tenni az új verziót a fenti parancsokkal.

Repó létrehozása

# mkdir -p /usr/local/etc/pkg/repos
# echo '
local: {
url: "file:///usr/ports/packages",
mirror_type: NONE,
enabled: yes
}
' > /usr/local/etc/pkg/repos/local.conf
# pkg repo /usr/ports/packages

Valahányszor a repóba új (vagy új verziójú) csomag került, az utolsó parancs, a pkg repo újrafuttatandó.

És végül a repó használata. Ha mázlink van, nincs hibaüzenet, csak jelzi, hogy a local nevű repóban hány csomagot talált.
# pkg update -r local

Updating local repository catalogue...
Fetching meta.txz: 100% 260 B 0.3k/s 00:01
Fetching digests.txz: 100% 376 B 0.4k/s 00:01
Fetching packagesite.txz: 100% 924 B 0.9k/s 00:01
Processing new repository entries: 100%
local repository update completed. 2 packages processed:
0 updated, 0 removed and 2 added.

Ettől kezdve a local repóban levő csomagok ugyanúgy telepíthetőek a pkg install paranccsal. A kimenetben még az is látszani fog, hogy honnan települ:

# pkg install -U lame
The following 1 packages will be affected (of 0 checked):

New packages to be INSTALLED:
lame: 3.99.5_1 [local]

The process will require 1 MB more space.
233 KB to be downloaded.

Proceed with this action? [y/N]:

Ha frissül egy csomag a repóban, vagy épp új csomag kerül fel, futtatandó a pkg repo parancs. És ahhoz, hogy ezt a frissülést érzékeljük, kell a pkg update. A pkg update nélkül még pkg rquery segítségével sem látjuk.
$ pkg rquery -r local -a %n-%v
(Ezzel lehet lekérdezni, hogy a local repóban milyen csomagok, milyen verzióval érhetők el.)

20141206. Mikulás update
Valami nem kerek. A legutóbbi update óta azt vettem észre, hogy nem hajlandó a lokális repót használni automatikusan, hanem boldogan használta a távoli repóban levő csomagot, hiába van nekem is a saját repóban ugyanolyan verziójú csomagom. Ezért ideiglenes megoldásként kénytelen vagyok kézzel hivatkozni erre a repóra:

pkg upgrade -U -r local lame

(Most épp nem a lame, hanem a faces csomag kapcsán derült ki a turpisság. Ennek még utána kell járni.)

Upd. 2:

Elvben a fenti probléma nem áll elő, ha a lokális repóból telepített csomag kap egy jelzőt a pkg annotate paranccsal. Nos ez eddig nekem nem tűnik működő megoldásnak, de azért ideírom. Tehát a man 5 pkg-repository szerint miután kiadtuk a pkg install -r local lame parancsot (esetleg miután frissítettük a "pkg upgrade -r local lame"-val, utána is?) jelezni kell a rendszernek, hogy ez a csomag ebből a repóból frissítendő. Ehhez adjuk ki a:

pkg annotate -A lame repository local

parancsot (nyilván a "lame" helyett az aktuális csomag, a "local" helyett pedig az aktuális repó nevét írva). Kár, hogy a lenti hozzászólások között tárgyaltakkal megegyezően most sem sikerült ez a jelzőt rátenni a csomagra - lévén eleve rajta van.

Jav. 2014.12.30.

No mit találok ma a freshports.org-on?

ports-mgt/pkg{,-devel} Update to 1.4.3 and 1.4.99.3
Changes:
...
- Document repository priority
...

Azaz mire újév lesz, addigra valószínűleg már tudni fogom, hogy mi a francot is kell csinálni ahhoz, hogy ez működjön. (Vagy legalábbis ebben bízom.)


Jav. 2015.01.18.

További fejlemények. Annyira előreléptek a multirepó támogatással, hogy megjelent a repók prioritása. Alapból egy repó 0-s (legalacsonyabb) prioritású, de a leiro.repo fájlban a (minő meglepetés)

priority: 1 (vagy nyilván valami nem-negatív egész)

kulcsszóval adhatunk neki nagyobb prioritást. És ekkor a magasab prioritású repót fogja a rendszer használni csomag előbányászásához. Heuréka. Ez az infó még a negyedéves státuszreport-ba is bekerült.
gépen a lokális repónak nagyobb prioritása, mint a hivatalosnak, szó nélkül húzta volna le a frissebbet távolról (a rohadt glib-1.2 és gtk-1.2-vel egyetemben). Úgyhogy jelenleg pkg lock faces && pkg upgrade && pkg unlock zajlott, aztán megcsináltam a frissebb csomagot és frissítettem lokális repóbol. Szóval ha észreveszem, kikerülni még mindig tudom a problémát De akkor is hogy lesz ebből unattended upgrade :-(

( uid_13349 | 2014. 08. 31., v – 10:05 )

Nagy köszönet, h ezt kidolgoztad és leírtad. Egy olyan pre-kezdő csomaghasználónak, mint én vagyok kicsit nehezen érthető a cél maga.
Tegyük fel, h egy adott állapotú rendszerem van, amit frissítenék, mondjuk portmasterrel (de lehet, h ez nem lényeges). Azt mondom neki, h használjon csomagokat, ahol lehet. Elér a lame-hez, nem talál a távoli repóban bináris csomagot. Leszedi hát a forrást, lefordítja és telepíti.

Ez elég egyszerűnek tűnik.
Ehhez képest mit ad a fenti?

Nem kell a portmaster-t használnod, hanem csak a pkg-t. Másrészt ha egyszer megcsináltad a lame csomagot, de utána eltávolítod (mert már nem kell), és találsz egy másik csomagot, ami fú de jó lesz, és a lame-től függ, akkor a lame-et nem kell még egyszer lefordítanod, hanem a pkg install fú_de_jó_másik_csomag paranccsal telepítheted, és a lame pedig a lokális repódból települ.

"Nem kell a portmaster-t használnod"
Nem nagy nyereség, de tény.

A fú_de_jó_másik_csomag frissítésével a lame nem frissül automatikusan, ha jól értem - a pkg csak használni akarja azt, ami a lokális repóból elérhető. Tehát egy általános/részleges csomagfrissítés előtt mindig ajánlott a lokális repó frissítés?

Hat amennyiben valtozott valami a lokalis repoban levo csomagjaid port-jaban, akkor azokat a csomagokat ujra kell ferditeni. Elvben a feltelepitett csomagjad kozul azok, amelyeknek a frissitesevel valamit trukkozni kell - azaz a kritikusabb dolgok - a pkg updating | more kimeneteben benne vannak datum szerint csokkeno sorrendben. Jellemzoen amugy opciovaltaskor, library verzioszam lepteteskor azert csomag verzioszamot is leptetnek, szobal eszreveheto tobbsegben.

A másik nyereséget itt írtam.

Egyébként a repót folyamatosan karban kell tartani, ez pedig hátrány.

Másik hátrány, hogy a karbantartás elég vacak: adott X, Y és Z port. Ha az Y-t akarod saját magad gyártani, és az függ az X-től, illetve a Z függ az Y-tól, akkor egy elég bolond helyzet előállhat:
- mindháromból megjelent egy új verzió
- pkg upgrade után az Y is frissül, a FreeBSD repóból
- ha tiltod Y frissülését, akkor valószínűleg Z se fog frissülni, függőség-hiba miatt, sőt, akár X se, mert Y-nak lesz egy törött függősége (libX.so.7 kell neki, viszont az új X-ben libX.so.8 van)
- X frissítése nélkül nem tudod frissíteni Y-t, mert az új Y-hoz új X is kell, goto előző pont, és ördögi kör

Persze ha olyan csomagokaz állítasz elő magadnak, amelyek "végfelhasználású" csomagok (tehát tőle már nem függ semmi), akkor lényegesen egyszerűbb a karbantartása.

Ahhoz kepest nem sokat :-). Jelenleg en erosen leszokoban vagyok a portmasterrol, mert abban bizom, hogy a pkgNG teljesen ki tudja valtani. En ket okbol alltam ennek neki:

- van (vagy csak volt) a pkgNG-nek egy furcsasaga (hibaja?) hogy ha van egy csomag (X), amit binarisbol tettem fel, de lokalisan, ports-bol forditottam es telepitettem valamely fuggoseget (Y), akkor amikor az eredeti csomag (X) a repoban frissult, akkor elakadt a pkg upgrade, nyafogott a "feloldatlan" Y-fuggoseg miatt. Fuggetlenul attol, hogy a fuggoseg telepitve volt. Eddig csak ugy tudtam kikerulni, hogy leszedtem a frissites elott X-et es Y-t, majd upgrade, es vissza. Ez meg akkor is maceras, ha amugy csinaltam csomagot Y-bol, es amikor visszatettem, akkor mar csak egy pkg add /usr/ports/packages/All/Y.txz && pkg install -U X modon raktam fel. Azzal, hogy csinaltam egy lokalis repot, azzal ezt a hulyeseget remelem kikuszoboltem (illetve hat a leirasok szerint innentol ennek mar nem szabad elofordulnia, hisz van repo, ahol ott csomag).

- a masik, hogy amig csak egy geped van, addig ez nem sokat dob. De tobb gep eseten mar megeri; pl ha van mondjuk egy NAS a zember gyerekenek lakasaban, az eppen mar tarolhatja ezt a keves, sajat-magamnak-muszaj-forditani csomagot. Ehhez persze a tobbi gepen mar nem lokalis, hanem tavoli repokent kell felvenni - de ez meg a jovo zeneje.

Tobb napja az a kenyszerkepzetem van, hogy azt olvastam valahol, hogy valamelyik pkg verziotol mar tudja (vagy tudni fogja) azt a pkgNG, amit fent a portmasterrol irtal: telepitesnel eszreveszi, hogy hiany van, es forditja lokalisan - no ez mar kb az a pont, amikor szamomra a portmaster elveszti jelentoseget, leven mas funkciojat szinte nem is hasznaltam akkor, amikor kb fel eve abbahagytam a hasznalatat. Azzal, hogy immar hetente (ritkabban kethetente) frissulo csomagok vannak az altalam hasznalt RELEASE-ekhez, nekem kelloen friss tud maradni a rendszerem.

( uzsolt v | 2014. 08. 31., v – 10:25 )

Ebben az esetben a tanácsom haszontalan, de csak a hajónaplónak, meg esetleg gondolatébresztőnek: ha foo_port port-ot saját beállításokkal fordítasz, és esetleg egy olyan csomagot akarsz telepíteni, ami ettől a foo_port-tól függ, akkor automatikusan le akarja szedni a központi FreeBSD repóból a foo_port-ból készített csomagot, mivel "options changed". A repókat a pkg ABC-sorrend alapján rendezi, tehát ha "local"-nak nevezed a repódat, akkor a "FreeBSD" repót hamarabb nézi, és onnan akarja foo_port-ot telepíteni (nyilván ha ott megtalálta - elvileg a lame esetében ez a veszély nem fenyeget).
Szóval ha ezt felül akarod írni (nyilván igen, mivel különben nem használnál saját beállításokat), akkor: 

pkg annotate -A foo_port repository local

ahol foo_port a port neve, a local pedig a repository neve, ahonnan telepíttetni akarod.

Viszont egy dolgot azért szem előtt kell tartani: ha a csomag, amelynek foo_port a függősége, és a saját beállításaid olyanok, hogy pont egy olyan beállítást kapcsoltál ki, ami a telepítendő csomagnak kellene, akkor könnyen probléma lészen. Ezt a pkg nyilván nem tudja kezelni, erre neked kell figyelni.

Ld. man pkg-repository => Working with multiple repositories.

Koszi, ezt az annotate-et meg akartam irni, de mivel egyelore meg csak olvastam rola, de nem teszteltem, ezert maradt ki. A lenyeg, ez is itt van mar neked koszonhetoen :-)
Egyre kevesebb olyan szar van, aminel a sajat opcioval forditas szamomra szukseges. Mondjuk akad egy-ketto, szoval azert fenti funkcio azert meg hasznos lehet. Ket-harom eve meg piszkosul odafigyeltem arra, hogy ha valami mukodik csak GTK-t hasznalva, de valamiert a ports-ban GNOME-fuggese van, akkor inkabb sajatot forditottam, mint hogy felpakoljak sok tiz megabajt szamomra folosleges cuccot. Vagy pl. a Claws-Mail-nek alapertelmezett opcioja a COMPFACE, aminek gyakorlatilag tok foloslegesen GTK-1.2-es default fugogsege van. Jelen esetben jo kompromisszum a mail/faces -t sajat opciokkal forditani sajat magamnak, es maris kihalhat a rendszerbol a gtk-1.2. Es mivel az kb 15 eve valtozott utoljara, sokkal kevesebb macerat allitok elo magamnak ezzel, mintha a CM-et forditgatnam magamnak.

No megnéztem ezt az pkg-annotate parancsot. Miután fentebb leírt módon feltettem mail/faces -t (tehát a saját repóból: pkg install -r local -U faces), közöltem vele:
# pkg annotate -A faces repository local
faces-1.7.7_9: Add annotation tagged: repository with value: local? [y/N]: y
pkg: faces-1.7.7_9: Cannot add annotation tagged: repository -- already exists
#

Ez nekem olybá tűnik, hogy valamiért ez beállítja magának. Hm. Ez nekem most jó, csak még azt nem látom, hogy hosszútávon jó lesz-e.
Szerk: pkg info szerint két annotation is van:
Annotations :
repo_type : binary
repository : local
Egyiket se én raktam oda :-)

Néha szoktam csak bináris csomagot telepíteni, a ccache eléggé meggyorsítja a fordítást.
Viszont a cdcat miatt nem akartam mindenféle plusz Qt-csomagot feltenni, ezért azt rögtön csomagból tettem fel, meg a függőségeit is (sima pkg install cdcat).
Itt mindegyiknél van repo_type és repository.

Nem lehet, hogy esetleg egy bizonyos pkg-verziótól kezdve van ez? Ez megmagyarázhatná azt, hogy miért van csak némelyik csomagon.

Ötletnek nem rossz, ami gyanús: nálam ugye 1.3.7 van (most, nem tudom mikor lesz verzióváltás), ami viszont annak ellenére, hogy azt írtak, hogy "ha ezt-és-ezt csinálod, akkor megelőzöd azt, hogy nagyon sok csomagodat újrarakja library változás miatt". No ennek ellenére 3 gépből 3 gépen csinálta azt, hogy a fenn levő csomagok minimum 80, de az egyiken kb a 98 %-át újrarakta :-( Ennek ellenére azon a gépen sincs csak pár csomagon annotation.

Egy frissen felrakott VM-ben már minden csomagnak van annotation-ja. A távolból és a lokálisan telepítetteknek is. Sőt, egy újdonsággal is találkoztam, a cpe nevű attributummal, ami nem tudom mi, de a curl, samba, perl és python csomagoknak van ilyenje; elsősorban valami verzió infóknak tűnnek. No majd csak találok ehhez is doksit.

( uzsolt v | 2014. 08. 31., v – 12:07 )

Kiegészítés:
Van lehetőség a WRKDIRPREFIX beállítására is, ahol a fordítást meg ilyesmit végzed. Ha ezt jól állítod be, és ha a /usr/ports/packages könyvtárat úgy hozod létre, hogy egy csoportnak vagy felhasználónak legyen írásjoga, akkor kb. a pkg update lesz az egyedüli parancs, amit root-ként kell használni. Ja, és persze ekkor csak egy make parancs kell: make package clean.

Másrészt van lehetőség "user-specified" make.conf megadására is, a __MAKE_CONF környezeti változó adja meg, melyik fájlt használja (érdemes ennek az első sorába egy .include "/etc/make.conf", hogy a különböző beállításokat megőrizze). Ebben a fájlban megadhatod a WRKDIRPREFIX, DISTDIR, PACKAGES változókat, sőt, akár a PORT_DBDIR-t is (az esetleges make config itt tárolja a port-specifikus beállításokat), így 99%, hogy csomag készítéséhez nem kell root jog (vannak olyan port-ok, ahol kell (a Makefile-ban NEED_ROOT=yes szerepel), ezért "csak" 99%).

Harmadrészt ha a PACKAGES nincs beállítva a make.conf-ban, akkor a PORTSDIR/packages könyvtárba kerülnek a csomagok (ld. man ports):

PACKAGES
Used only for the package target; the base directory for the packages tree, normally packages/ in PORTSDIR.

Csak a vegere reagalok. A man ports szerint oda kene kerulni, de mint fent irtam, az egyik gepemen nem sikerult neki odakerulnie, siman a make package utan csak a work/pkg alatt volt, oszt csokolom. De ez siman lehet az adott gepen valami altalam nem eszrevett hiba - a konyvtar megvolt, ez biztos. (Az mas kerdes, hogy fenti idezetedet en szemely szerint ugy ertelmezem, hogy azt jelenti: ez a szokvanyos beallitas; nem pedig azt jelenti, hogy a nem beallitott PACKAGES hijjan ide kerulnek a csomagok.)

Na, erre most kiváncsi lettem. Ki is próbáltam, a /etc/make.conf-ban a PACKAGES sort kikommenteltem, PACKAGES környezeti változóm sincs. Ekkor a make package a /usr/ports/packages-ba készítette el a csomagot.
Megnéztem a Mk/bsd.port.mk fájlt, abban van egy ilyen sor: 

PACKAGES?=		${PORTSDIR}/packages

Szóval úgy vélem, hogy valami "nem észrevett hiba" lehet azon a gépen. Nem lehet, hogy van egy ilyen környezeti változód? A make -V PACKAGES az adott port-könyvtárban mit mond?

( uzsolt v | 2014. 12. 06., szo – 13:54 )

20141206. Mikulás update
Valami nem kerek. A legutóbbi update óta azt vettem észre, hogy nem hajlandó a lokális repót használni automatikusan, hanem boldogan használta a távoli repóban levő csomagot, hiába van nekem is a saját repóban ugyanolyan verziójú csomagom. Ezért ideiglenes megoldásként kénytelen vagyok kézzel hivatkozni erre a repóra

Elvileg kell egy annotate arra a csomagra, amit a saját repódból akarsz telepíteni (ld. man pkg-repository, "Working with multiple repositories" rész).
Gyakorlatilag meg... a fene tudja. Nem egészen úgy működik, ahogy számítok rá. Vagy a fene ese tudja.
Az xorg-video-ati csomagot nem akarom frissíteni, mivel az újban nincs "ClockGatingMode" meg "ForceLowPowerMode", ami nekem kellene - nem szeretem, ha gyakorlatilag semmit nem használok a laptopomon, és a venti folyamatosan megy a videókártya miatt. Szóval van egy (saját készítésű) csomag a /usr/ports/packages/All-ban a régi verzióból, de a pkg upgrade hatására le akarta szedni a hivatalos tárolóból a frissebbet. Ezt csak úgy tudtam megakadályozni, ha a pkg lock-ot használtam.
Viszont egy másik esetben (másik csomagnál) a pkg upgrade hatására kiírta, hogy a /usr/ports/packages/All-ban nem találja, és bezárt a bazár.

A fórumon itt felvetettem a problémát, de valahogy nem érkezett olyan válasz, amellyel tisztábban láttam volna. Szerintem ez még nem annyira (ki)használt lehetőség, így még jópár sebből vérzik.

A leírásomból mindenképp hiányzik, de a vicc az, hogy van rajta annotation tag. (Meg volt is, ennek ellenére frissült az _9-ről _10-re a távoli repóból.) Mondjuk nekem az teljesen jó megoldás, ha az annotation hatására leáll a frissítés. Nyilván akkor jó, ha mondjuk a csomagok letöltése közben áll le és anyázik. Ekkor az ember megcsinálja az új csomagot a lokális repóban, újraindítja a pkg upgrade-et, és nem lesz belőle gáz azáltal, hogy kap a közpoti repóból újabb (természetesen másmilyen függőséggel / másmilyen opciókkal fordított csomagot.)

( uzsolt v | 2014. 12. 30., k – 11:58 )

Jav. 2014.12.30.

No mit találok ma a freshports.org-on?

ports-mgt/pkg{,-devel} Update to 1.4.3 and 1.4.99.3
Changes:
...
- Document repository priority
...

Azaz mire újév lesz, addigra valószínűleg már tudni fogom, hogy mi a francot is kell csinálni ahhoz, hogy ez működjön. (Vagy legalábbis ebben bízom.)

Hát, szerintem ezzel nem fogsz/fogunk előrébb kerülni. Letöltöttem az 1.44.9.3-as verziót, de a pkg-repository.5 man ugyanaz (legalábbis ez a része). Másrészt nem a sorrenddel van a baj, hanem azzal, hogy az annotation nem működik úgy, ahogy várjuk (és ahogy a doksi is írja).
Én inkább ehhez fűznék reményeket:

pkg 1.4.3 brings lots of fixes for multi repository:
CONSERVATIVE_UPGRADE (to put in pkg.conf) to ensure a package has priority from where it was installed from
priority: (to put in repository configuration files) to make a repository having hight priority than others

Bár az is lehet, hogy a "Document repository priority" inkább erre utal.