( egmont | 2007. 01. 08., h – 17:44 )

Igaz, hogy csak két csomagkezelőt ismerek közelebbről (dpkg és rpm), de egyik sem "néz körül" a fájlrendszeren, és ebben igazat adok nekik: a függőséget kizárólag saját adatbázisukban ellenőrzik. Mégis, például a libc.so.6-ot milyen útvonal mentén kellene ellenőriznie? És ha azt látná, hogy most ott van, hogyan tudná garantálni, hogy ott is maradjon? Normális, konzisztens, jól specifikált, átlátható szoftvereket lehet írni, ha abból indulsz ki, hogy saját fájljaikat menedzselik. Ha azt szeretnéd, hogy az egyéb módon telepített fájlokat is vegyék észre, és félig kezeljék, hatalmas káosz lesz, már a funkcionalitást sem tudod épeszűen specifikálni. Egyébként az RPM esetén úgy tudom, hogy a Requires: és Provides: értékek mindig pusztán stringek, még akkor is, ha történetesen úgy néznek ki, mint egy fájlnév, akkor is valójában csak sztringek, és arra ellenőriz, hogy amit valaki Require, azt másvalaki Provide-e, és még csak azt sem nézi meg, hogy fájlként szállítja-e. Bár lehet hogy erre rosszul emlékszem.

Egyébként pontosan az ilyen szituációk kedvéért létezik a --nodeps. Nem tudom, mi bajod vele. Ha nem lenne ilyen opció, érteném nyűgödet. Ráadásul az rpm gyönyörűen együtt tud élni teljesítetlen függőségekkel, ellentétben például a dpkg apt-jával, amelyik egy ilyen láttán azonnal elutasítja, hogy bármiféle (a teljesítetlen függőséggel nem érintett) csomagot felrakjon vagy frissítsen.

Apropó, miért nincs /bin/sh meg libc.so.6 az rpm adatbázisodban? Rpm alapú disztribet használsz? Ha igen, akkor ezeknek benne kell lenniük az adatbázisban. Ha nem, akkor mit vársz az rpm-től? Fogadd el a --nodeps-t, vagy használj alient, vagy az RPM-mel csak csomagoltasd ki az archívumot, de ne bízd rá a menedzselést.