Re: ITP: lirc, devfsd

2000-04-03 Thread Ben Collins
 Similarly, I have packaged devfsd (http://www.atnf.csiro.au/~rgooch/linux/).
 This one still needs a couple of problems ironing out first.

No offense, but I hope you realize the amount of effort that will be
needed for devfsd. Since it is a key element in our 2.4.x upgrade path,
the amount of policy and technical bugs will be tremendous (permissions,
adding support for default compatibility devices, etc..).

I just don't want to see anyone go lightly into packaging devfsd. If you
aren't prepared to take on the responsiblity of what will most likely
become a base and essential package, leave it for some one else to do.

-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
` [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED] '
 `---=--===-=-=-=-===-==---=--=---'



Re: ITP: lirc, devfsd

2000-04-03 Thread Ethan Benson
On Sun, Apr 02, 2000 at 10:09:30PM -0400, Ben Collins wrote:
  Similarly, I have packaged devfsd (http://www.atnf.csiro.au/~rgooch/linux/).
  This one still needs a couple of problems ironing out first.
 
 No offense, but I hope you realize the amount of effort that will be
 needed for devfsd. Since it is a key element in our 2.4.x upgrade path,
 the amount of policy and technical bugs will be tremendous (permissions,
 adding support for default compatibility devices, etc..).
 
 I just don't want to see anyone go lightly into packaging devfsd. If you
 aren't prepared to take on the responsiblity of what will most likely
 become a base and essential package, leave it for some one else to do.

I hope debian is not planning on `forcing' [0] the use of devfs with 2.4,
last i checked it was still a compile time option (and experimental at
that) there are some of us who don't care for devfs and do not wish to
use it.

[0] read making it exceedingly inconvenient to forgo or disable devfs
in 2.4 kernels, for example neglecting to maintain or provide a real
(non-devfs) working /dev directory.

-- 
Ethan Benson
http://www.alaska.net/~erbenson/


pgpIttMdLg8tg.pgp
Description: PGP signature


Re: ITP: lirc, devfsd

2000-04-03 Thread Ben Collins
On Sun, Apr 02, 2000 at 06:42:59PM -0800, Ethan Benson wrote:
 On Sun, Apr 02, 2000 at 10:09:30PM -0400, Ben Collins wrote:
   Similarly, I have packaged devfsd 
   (http://www.atnf.csiro.au/~rgooch/linux/).
   This one still needs a couple of problems ironing out first.
  
  No offense, but I hope you realize the amount of effort that will be
  needed for devfsd. Since it is a key element in our 2.4.x upgrade path,
  the amount of policy and technical bugs will be tremendous (permissions,
  adding support for default compatibility devices, etc..).
  
  I just don't want to see anyone go lightly into packaging devfsd. If you
  aren't prepared to take on the responsiblity of what will most likely
  become a base and essential package, leave it for some one else to do.
 
 I hope debian is not planning on `forcing' [0] the use of devfs with 2.4,
 last i checked it was still a compile time option (and experimental at
 that) there are some of us who don't care for devfs and do not wish to
 use it.
 
 [0] read making it exceedingly inconvenient to forgo or disable devfs
 in 2.4 kernels, for example neglecting to maintain or provide a real
 (non-devfs) working /dev directory.

No this is not an option. There will remain a real /dev for (an I presume
and support this particular viewpoint, but it has not been set in stone as
of yet, and wont be until potato is out of the way, and 2.4 is in woody)
atleast woody, and most likely the release after that. I would hope that
we can have a completely devfs system for the release after woody, simply
because it is the way that everything is going, and it is the Right Way.

Note that makedev can create all of the base devices with one simple
command. This makes it quite simple to get rid of devfs, even in the
future if we ever do decide not to provide it by default on later
distributions (in fact this can probably be scripted, so that if the
system boots without devfs enabled, makedev will create everything needed
on the fly).

However, people will want to use devfs, and therefore devfsd will be
needed in order to support the transition (without it, most programs will
fail to find the new device locations). I am pretty sure that devfs will
be used extensively in boot-floppies. The main reasons being that the
rootdisks will be smaller without having to contain hardcoded device
nodes. Secondly, it is easy to parse out what the available hardware is
since the device nodes are only created when a driver actually finds the
device and enables it (i.e. /dev/cdroms/cdrom0 wont exist unless there is
actually a cdrom device). Since the boot-floppies are self contained, it
wont even need devfsd for the installation program, since all the device
paths can be made to work with devfs' setup.

Again, these are my opinions alone, and nothing has been decided, but
devfs will come of age, and we need to support it, and that will mean some
work for the devfsd maintainer, whoever that may be.

Ben

-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
` [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED] '
 `---=--===-=-=-=-===-==---=--=---'



Re: ITP: lirc, devfsd

2000-04-03 Thread Rainer Clasen
On Sun, Apr 02, 2000 at 10:16:42PM +0100, Tom Lees wrote:
 LIRC is Linux Infra-red Remote Control support, see
 http://fsinfo.cs.uni-sb.de/~columbus/lirc/index.html

Ist it compiled for only one certain receiver type + port? Or were you able
to make it configurable?



Rainer

-- 
KeyID=58341901 fingerprint=A5 57 04 B3 69 88 A1 FB  78 1D B5 64 E0 BF 72 EB



ITP: lirc, devfsd

2000-04-02 Thread Tom Lees
I have packaged LIRC and will upload it later today or tomorrow if
noone objects.

LIRC is Linux Infra-red Remote Control support, see
http://fsinfo.cs.uni-sb.de/~columbus/lirc/index.html

Similarly, I have packaged devfsd (http://www.atnf.csiro.au/~rgooch/linux/).
This one still needs a couple of problems ironing out first.

-- 
Tom [EMAIL PROTECTED]

Captain's Log, star date 21:34.5...