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

Re: Possible bug in devfs package and bugs reporting in general



Vesselin Kostadinov <Vesselin.Kostadinov@Beonic.com> writes:

> I had to mess around with few packages, one of them being devfs. It
> looked easy:
>
> apt-get devfs
>
> So apt downloaded and configured it. I thought I was done with it
> and I can concentrate on the other (more important to me)
> packages. Not so. After "become-an-expert-in-devfs" exercise I
> figured out that I had to recompile the kernel to support devfs.

I don't really think this is unreasonable; for something like a
filesystem (and in particular, something as unusual and exotic as
devfs) the general expectation is that the user knows what they're
doing and why they're installing what they are.  Being able to run
apt-get isn't a substitute for feeding 'devfs' into Google.  :-)

> I was thinking that in an ideal world the configuration of 
> a package would fail if at least one of it's prerequisites 
> (like certain kernel functionality) is not met. This would 
> (1) tell the user what is wrong and (2) leave the package 
> in "Failed-config" state so all packages that depend on this 
> one would not be installed until the issue is resolved.

This is the case for normal user-space software, but not really for
kernel stuff.  For example, if you're using woody, you might try to
get support for hardware sensors, 'apt-get install lm-sensors', and be
told that this depends on lm-sensors-mod, which doesn't exist.  My
most useful piece of advice here, I think, is to not try to use
apt-get as your only package management tool; sometimes you want to
use dpkg directly, but other times it's useful to have the package
description available somewhere you can easily look at it.  (In the
lm-sensors case, the description would point you at the
lm-sensors-source package, which you'd use to build the kernel
modules.)  I recommend aptitude as a good APT frontend.

> 1. Should I report this as a bug? It is a bug in a sense 
> that a required functionality does not work "out-of-the-box". 
> However, strictly speaking, there is no bug in devfs package - 
> it is up to the poor user to figure out what is wrong with 
> the rest of the system.

"Package silently does nothing when installed" typically *is* a bug.
But in the particular case of devfsd, I wouldn't consider it so.  A
devfs system is largely useless without devfsd running, since device
files like /dev/hda and /dev/tty1 won't exist.  How do you switch to
devfs in the first place?  In this case, it's fine to install devfsd
when you're using a non-devfs kernel, and it does nothing, but when
you reboot with your devfs-enabled kernel devfsd starts up and makes
sure the symlinks you expect really do exist.

(It's also very hard to have a dependency on "has some kernel feature"
where that feature isn't some set of modules that's always distributed
separately from the kernel, at least in the dpkg arena; if nothing
else, the user could reboot to a different kernel that did or didn't
have that feature.)

> 2. Is there a manual/gude/faq that already explains what
> exactly is a bug and that should be RTFM before asking 
> question 1?

You might look at http://bugs.debian.org/.  Also note that there is
the "wishlist" bug severity, meaning "it'd be nice if this changed".

-- 
David Maze         dmaze@debian.org      http://people.debian.org/~dmaze/
"Theoretical politics is interesting.  Politicking should be illegal."
	-- Abra Mitchell



Reply to: