[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: replacing makedev



We reimplement it because we have different needs.  For example,
the one I'm working on has the following bit of code:

ext = strrchr (file->d_name, '.');
if (ext == NULL)
	read_file (file->d_name);
else if (strcmp (++ext, os) == 0)
	read_file (file->d_name);

where 'os' defaults to linux, but can be set w/ MAKEDEV -o "netbsd".
Other distributions aren't going to want this, and there's no reason why
we need to share this; makedev isn't a mutable organism (well, it
shouldn't be, if done correctly).  The things that change will be in
/etc/makedev.d, and will be distributed amongst other packages
(ideally).

Conectiva uses the same MAKEDEV script we do.  Redhat uses their own.
Slackware doesn't even have a MAKEDEV.  Mandrake uses redhat's.  They
have different needs; trying to have a "one true makedev" seems almost
counterproductive.  If we conform to redhat's makedev, we break stuff;
if they conform to ours, they break stuff.  If we create a makedev w/
features from every distro, we create a bloated mess that will probably
end up being forked anyways (easier for distros to patch their rpms/debs
than to coordinate w/ upstream).

BTW, for those who don't speak C; the above checks if a filename has an
extension; if not, read it in; if so, check if the extension matches the
OS.  So, /etc/makedev.d/foo and /etc/makedev.d/bar.linux would be read
in, while /etc/makedev.d/baz.freebsd would be ignored (assuming the os
is linux).

On Sun, Jul 07, 2002 at 09:07:18PM -0700, Sean 'Shaleh' Perry wrote:
> 
> 
> On 07-Jul-2002 Andres Salomon wrote:
> > I've started work on this, but I figured I'd shoot an email to the list
> > for suggestions/comments.  The current makedev script (/sbin/MAKEDEV) is
> > rather lacking in a few respects:
> > 
> 
> If you are going to do this, how about doing it seriously.
> 
> Contact the other Linux dists and come up with the "one true makedev".  Right
> now every linux dist has a slightly different version.  I see no reason for all
> of us to keep reimplementing this.

-- 
Broad surveillance is a mark of bad security.
	-- Bruce Schneier


-- 
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: