A DragonflyBSD is a pkgsrc-t fogja használni

> A BSD-k "bleeding edge"-e, a DragonflyBSD következ? kiadását - amely
> decemberre várható - már a NetBSD team által fejlesztett pkgsrc [0] forrás

Nah gratulalok... pkgsrc-t checkoutoltam, asszem tan joe-t akartam make, es
elhasalt a picsaba. De barmi mas is amit probaltam... Szoval nalam bebukta.
Valahogy biztos mukodik, de a ports elsore is ;)

pkgsrc minden csak nem portolhato. nem egy operacios rendszen probaltam es szanalmas eredmenyek jottek ki belole. pkgsrc minden csak az nem aminek mondjak.

Inkább portage-et kellene megpróbálniuk, az igen jól portolható, és mára a portage vált a legfejlettebb forrás alapú csomagkezelővé.

régi netbsd fanként egyre szimpatikusabb nekem ez a dbsd :) egyébként a pkgsrct legegyszerűbben a pkgsrc.org [www.pkgsrc.org]-n keresztül lehet elérni.

Remélem annyit azért tudsz, hogy a portage erősen hajaz (lévén abból alakult ki) a FreeBSD|OpenBSD|DragonFlyBSD eredeti ports mechanizmusára - és épp azt hivatott DFLy-ban kiváltani a NetBSD-s pkgsrc. Amúgy azért tisztán kiváncsiságból érdekelne, hogy mitől a portage az a bizonyos legfejlettebb? Tehát mitől _több_, mint pl. a FreeBSD-ben benne levő ports/portupgrade páros?

A portage csomagjai pythonban vannak megírva. Még a ports a gnu automake mechanizmusának a "meghackelése". Bár ettől az még nem kevesebb, de nem olyan elegáns mint a portage.

Konkrátumok, a portage számtalan verzió kezelésére alkalmas egy csomag esetében még a ports csak egy verziót kezel. Csomagon eltávolításánál is van mód a függőségek kezelésére, revdep-rebuild-el így nem maradnak működésképtelen programok. Portsban ez nincs. A többféle maszkolásnak köszönhetően lehetőség van a legújabb csomagok telepítésére, amennyiben hibásan működnek, bármikor vissza lehet térni valamelyik régebbi stabil verzióra. Ports esetében ha bekerül egy teszt csomag és updatelek rá, majd a rosszul működik, akkor nincs visszaút várhatok amég kijavítha a karbantartója.

Ennyi szerintem épp elég, hogy jobb legyen.

Lehet downgrade-elni a portokat. A gentooval meg az a baj, hogy linux.

> mit?l a portage az a bizonyos legfejlettebb?

Azon borzaszto egyszeru oknal fogva, hogy mukodik.

--
Gabucino

Picit részletesebben? Nekem a ports is működik, immár 10 éve használom.

1) Az, hogy milyen nyelvben van implementálva, nem sokat mond arra vonatkozóan, hogy jó vagy nem. "Az igazi programozó minden programozási nyelven tud Fortranban programozni".

2) A ports egyáltalán nem épít a gnu féle automake -re. A fejlesztők közül meglehetősen sokan eléggé rosszul állnak az autotool-okhoz (és a szinte hozzáragasztott Linuxism -hez). Speciel a normál (igaz nem GNU, hanem BSD) make az alapja. Ami pedig tudtommal egy kiforrottabb (de legalábbis régebb óta létező) eszköz, mint a Python.

3) Én is le tudok szedni függőséggel rendelkező (vagy éppen valamihez szükséges) csomagot. Örülnék, ha elmagyaráznád, hogy mit csinál a Te portage-ed által kezelt mplayer, ha a grafikus felületéhez nélkülözhetetlen GTK1.2-s csomagot (és vele a GTK1.2-s libet) leszedem, majd elindítom a gmplayer-t? Ha az utalás arra vonatkozik, hogy leszedi a GTK12-t, de fennhagyja a függőség miatt magát a libet, akkor értem, de szabadon henteregni egy senkihez nem tartozó libnek - nos ez számomra nem egy életbiztosítás. Hol hagyja? Az eredeti, normál helyén? Akkor majd jön valaki, és elkezdi használni - pedig nincs is fenn minden része a csomagnak. Ha máshova teszi, akkor meg szerintem sok ilyen után eléggé össze fog kuszálódni.

4) Downgrade nem is létezik a portsban? Már miért ne?

5) Én magam is javíthatom lokálisan. (Nálam is van 2-3 ilyen javított csomag évek óta, de nem zavar a rendszerben senkit.)

A downgrade azt jelenti, hogy lehet _egyszerre_ a gepeden ugyanabbol a csomagbol mondjuk 3 kulonbozo verzioszamu?

danesdzsu wrote:
> A downgrade azt jelenti, hogy lehet _egyszerre_ a gepeden ugyanabbol a
> csomagbol mondjuk 3 kulonbozo verzioszamu?
Sosem használtam gentoot, de érdekelne, hogy ezt hogy oldják meg. Minden
fájlt, ami a csomaghoz tartozik egy verziószámozott könyvtárba tesznek
és megpatchelik az összes programot (már amelyiket szükséges), hogy ott
keresse a dolgait?

On 2005-09-03, Gabucino <gabucino@mplayerhq.hu> wrote:
> Nah gratulalok... pkgsrc-t checkoutoltam, asszem tan joe-t akartam make, es
> elhasalt a picsaba. De barmi mas is amit probaltam... Szoval nalam bebukta.
> Valahogy biztos mukodik, de a ports elsore is ;)

Nem aszonta Dillon, hogy qrvajo a pkgsrc as of now, s aki kiprobalja el
is elvez tustent, ez egy hosszutavrol/ra szolo dontes.

Szemelyes tapasztalataim nem jok amugy a pkgsrc-vel, Dfly es Linux
alatt is probaltam, egy sz@ros glib-2-n is szepen elhasalt.

De ha a Dfly sracok raallnak, es testreszabjak, ugy hogy az mukodjon
nekik, aztan kommitaljak upstream, akkor lesz ertelme.

Jobb, mint egy hackywacky patchsetet patchelgetni -- amit csinalnak
bekerul majd a pkgsrc faba annak rendje es modja szerint. Es azt
belattak, hogy arra nincs manpowerjuk mar, hogy scratchbol oszzerakjak a
nextgen package management systemet...

Esetleg meg a portage lehetne alternativa, mindjart meg is valaszolom az
ezugyben iro kollega levelere, miert nem.

Cs.

On 2005-09-04, zoozo <kukamax@freemail.hu> wrote:
>
> A portage csomagjai pythonban vannak megírva. Még a ports a gnu automake
> mechanizmusának a "meghackelése". Bár ett?l az még nem kevesebb, de nem
> olyan elegáns mint a portage.
>
> Konkrátumok, a portage számtalan verzió kezelésére alkalmas egy csomag
> esetében még a ports csak egy verziót kezel. Csomagon eltávolításánál is
> van mód a függ?ségek kezelésére, revdep-rebuild-el így nem maradnak
> m?ködésképtelen programok. Portsban ez nincs. A többféle maszkolásnak
> köszönhet?en lehet?ség van a legújabb csomagok telepítésére, amennyiben
> hibásan m?ködnek, bármikor vissza lehet térni valamelyik régebbi stabil
> verzióra. Ports esetében ha bekerül egy teszt csomag és updatelek rá, majd
> a rosszul m?ködik, akkor nincs visszaút várhatok amég kijavítha a
> karbantartója.
>
> Ennyi szerintem épp elég, hogy jobb legyen.

Jaja, a portage-n ott virit szamos bell and whistle, harom merfoldre
elragyog, mint a karacsonyfa, ha felgyujtja a csillagszoro, csak eppen
az egesz alapkoncepcio hardcore linux-specifikus, nem alternativa mas
oprendszernek.

Mirol is beszelek? Arrol, hogy az, hogy a portage mindent
/{,usr}/{lib,bin,include}-ba rak es ez bele van vasalva. Egetve.
Nincs mod alternativ installacios hely megadasara. Nincs olyan valtozo
az ebuildekhez, ami a --prefix erteket allitana a configure scripteknel.
Van $ROOT, de az mas. Ha a vimet --prefix=/kutyafarka kapcsoloval
istallalod, megtalalja a szintaksz fajljait minden tovabbi nelkul, ha
ROOT=/kutyafarka-val, akkor nem, ugyanugy a default hierarchiaban levo
share konyvtarban fog keresni utana.

Es az, hogy az alaprendszer nicsn elvalasztva a 3rdparty stufftol, es
minden be van nyomoritva a /{,usr}/{lib,bin,include} ala, ez affele
Linux betegseg, BSD-k alatt nem igy van, es a BSD-s ports-szerusgeknel
mind rendesen allithato a prefix.

Szoval: portage nem alkalmas. (A fentiek orvoslasa TODO a portage devel
page-en is, ha megnezed, de meg nemi viz le fog folyni a Dunan, mig
odajutnak).

Cs.

On 2005-09-05, danesdzsu <danesdzsu@freemail.hu> wrote:
> A downgrade azt jelenti, hogy lehet _egyszerre_ a gepeden ugyanabbol a
> csomagbol mondjuk 3 kulonbozo verzioszamu?

Na de tudtommal ez nem ugy megy, hogy John Doe eldonti, hogy x
programbol fenn lesz neki a devel is meg a stable is, hanem csak
ott mukszik, ahol az ebuild csinalo szepen beszlotozta a csomagot, es
ez csak par kritikus csomagnal van igy (autotools, gcc...)

Ha ez igy van, akkor mar egyaltalan nem olyan vonzo ez a feature, inkabb
egy hack, ami arra szolgal, hogy orvosolja az alaprendszer es a rest
szeparacioajat...

A pkgsrc ebben tenyleg elorebb all. A csomagok nagy (es novo) reszenel van
pkgviews tamogatas, amhol tenyleg a juzer donti el, mibol mit mennyit
rak fel.

Cs.

Nem tudom az eredeti kérdésfelvetőnél pontosan mit jelent a downgrade, de erre az a válaszom, hogy a fenti igényt hack nélkül tudja a ports (legalábbis bizonyos dolgokhoz már elkészült). Itt egy rövid részlet:

$ pkg_info -Ix auto libtool

autoconf-2.13.000227_5 Automatically configure source code on many Un*x platforms

autoconf-2.53_3 Automatically configure source code on many Un*x platforms

autoconf-2.59_2 Automatically configure source code on many Un*x platforms

automake-1.4.6_2 GNU Standards-compliant Makefile generator (legacy version

automake-1.5_2,1 GNU Standards-compliant Makefile generator (version 1.5)

automake-1.9.6 GNU Standards-compliant Makefile generator (1.9)

libtool-1.3.5_2 Generic shared library support script (version 1.3)

libtool-1.5.20 Generic shared library support script (1.5)

Azaz pl. az auto* és a libtool vackokból _hack_ nélkül van fenn a gépemen két ill. három különböző verzió. Mer' az egyik szoftver ezt szereti, a másik meg azt. Ha az lenne a kérdés, hogy 1.4-es automake -ből fel tudok-e rakni egyszerre 1.4-et, meg 1.4.6 -ot, nos tudtommal nem, de ha szükséges, meg tudom csinálni, hogy abból valamiért egy régebbi legyen fenn, mint ami hivatalosan a ports része - ha valamiért az kellene.