/usr/share/hal/fdi/policy/20thirdparty/ i /usr/lib/hal/

Fryderyk Dziarmagowski freetz w gmx.net
Sob, 5 Sty 2008, 11:06:09 CET


On Sat, 5 Jan 2008 10:49:35 +0100
Fryderyk Dziarmagowski <freetz w gmx.net> wrote:

> On Fri, 4 Jan 2008 16:19:20 +0100
> "Patryk Zawadzki" <patrys w pld-linux.org> wrote:
> 
> > 04-01-08, Fryderyk Dziarmagowski <freetz w gmx.net> napisał(a):
> > > On Fri, 4 Jan 2008 13:54:01 +0100
> > > "Patryk Zawadzki" <patrys w pld-linux.org> wrote:
> > >
> > > > Jak w temacie, biblioteki, które używają hala instalują tam
> > > > swoje rzeczy, przez co wymagają hala. Hala z kolei nie ma i nie
> > > > będzie na builderach, bo hal używa udeva, którego tam nie ma i
> > > > nie będzie.
> > >
> > > To bibliotekę należy poprawić poprzez wydzielenie części zależnych
> > > od daemona hal, a nie odwrotnie.
> > 
> > Żeby działała jak trzeba, musiałbym dodać do niej R: hal-%{name} i
> > wracamy do punktu wyjścia. :)
> 
> Nie biblioteka, tylko program używający jej potrzebuje takie R:

Zadałem sobie minimum trudu i zajrzałem do tools/Makefile.am
gdzie widać, że libgpod dostarcza hal_PROGRAMS, które to wymagają hala,
a nie jak zasugerowałeś sama biblioteka.
Należałoby wydzielić libgpod-tools i to one muszą wymagać hala.
Reszta to S: w programach o libgpod opartych.

-- 
Fryderyk Dziarmagowski


Więcej informacji o liście dyskusyjnej pld-devel-pl