DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=subject:from:to:content-type:date:message-id:mime-version:x-mailer
         :content-transfer-encoding;
        b=CS+NHZkueGc0LmINMPoewWpJ3hAOypi14r+l1zDaFK34Jrfmc/XPxpSgCxF5emvYfD
         /CRQBD4s0miLc3c9RD9tPGKefHQsXkfj9uaRGYFwbt78+Gr5yQXRPBPmd+Sg//uNF31i
         J6hqdMrb8ORPgmHPnZhir+bGlm86X8J552kA0=
Subject: [alpine-devel] testing/dahdi-tools depenendency question
From: Natanael Copa <natanael.copa@gmail.com>
To: alpine-devel@lists.alpinelinux.org
Content-Type: text/plain
Date: Thu, 12 Mar 2009 18:45:06 +0100
Message-Id: <1236879906.7342.14.camel@ncopa-laptop>
Precedence: list
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

fabled,

I wonder if we really need the dahdi-linux dependency for dahdi-tools.
The problem i think we might get is that the kernel modules are on the
readonly modloop loopback, not registered in apk database.

Not sure, but also in a vserver guest enviroment, we will not be able to
load the kernel modules (must be done by the host) but it might be
possible to give access to dahdi devices in the guest.

Other situations might be when users build their own kernel and have the
dahdi drivers in kernel rather than as modules or have another kernel
flavore (vanilla kernel, vserver kernel...)

Point is, we probably dont want to have kernel modules as dependencies
for the userland tools.

Also, i wonder if we maybe should rename the dahdi-linux package to
dahdi-linux-grsec. We might want dahdi modules for other kernel flavors.

-nc



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---