Why is linux-2.6.13 wanting to remove devfsd ? Is there really some reason why devfsd binary must be uninstalled ? I know, you are dropping support for devfs (BTW, is that really dropped from kernel, or are you only stating it's not supposed to work anymore ?). But isn't still possible to use multi-kernel configuration and use devfsd with older (perhaps 2.4) kernels and udev with 2.6 ? (Note: I, personally, have devfs on /dev/DEVfs/ for comparsion purposes and I'm managing static device nodes all times from 2.0.29 ... using tar in udev. I hope you don't plan to remove that.) Reproducible: Always Steps to Reproduce: 1. emerge gentoo-sources Actual Results: [blocks B ] sys-fs/devfsd (is blocking sys-kernel/gentoo-sources-2.6.13-r3) [ebuild NS ] sys-kernel/gentoo-sources-2.6.13-r3 -build +doc -symlink (-ultra1) 198 kB Expected Results: Only warn, that devfsd is unsupported on 2.6.13+ (isn't it doing that anyway ?) Portage 2.0.51.22-r3 (default-linux/x86/2005.0, gcc-3.3.2, glibc-2.3.4.20040808-r1, 2.6.12-gentoo-r4 i686) ================================================================= System uname: 2.6.12-gentoo-r4 i686 AMD Duron(tm) Processor Gentoo Base System version 1.6.13 distcc 2.16 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] dev-lang/python: 2.3.5-r2 sys-apps/sandbox: 1.2.11 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.4.3-r4, 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -mcpu=athlon -march=i686 -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/afs/C /etc/afs/afsws /etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -mcpu=athlon -march=i686 -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distcc distlocks sandbox sfperms strict" GENTOO_MIRRORS="ftp://ftp.tu-clausthal.de/pub/linux/gentoo http://ftp.sh.cvut.cz/MIRRORS/gentoo/gentoo/ http://www.mirror.ac.uk/sites/www.ibiblio.org/gentoo/ http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="x86 3dnow 3dnowex X Xaw3d aalib afs alsa apache2 apm arts avi bash-completion berkdb bitmap-fonts caps cdr crypt cups curl dga divx4linux doc dvd emboss encode erandom esd flac foomaticdb fortran fpx gcj gd gdbm ggi gif gpm graphviz gstreamer gtk gtk2 imagemagick imlib innodb ipv6 java jbig jpeg lcms lesstif libcaca libg++ libwww live lzo mad mailwrapper mbox mcal memlimit mikmod mmx mng motif mozilla mp3 mpeg multislot mysql ncurses network nls ogg oggvorbis opengl oss pam pdflib perl pic png python qt quicktime readline real ruby samba sdl slang snmp spell sqlite sse ssl svga tcltk tcpd tetex theora tiff truetype truetype-fonts type1-fonts unicode usb userlocales vhosts videos vorbis wmf xgetdefault xml xml2 xmms xosd xv xvid zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
It's actually worse than that! Portage thinks you *shouldn't* remove devfsd! DreamGate etc # emerge -pvuDN world These are the packages that I would merge, in order: Calculating world dependencies ...done! [blocks B ] sys-fs/devfsd (is blocking sys-kernel/gentoo-sources-2.6.13-r3) [ebuild NS ] sys-kernel/gentoo-sources-2.6.13-r3 -build -doc -symlink (-ultra1) 198 kB [ebuild U ] sys-libs/glibc-2.3.5-r2 [2.3.5-r1] -build -erandom -glibc-compat20 -glibc-omitfp -hardened -linuxthreads-tls (-multilib) +nls -nptl -nptlonly -pic -profile (-selinux) +userlocales 24 kB Total size of downloads: 223 kB DreamGate etc # emerge -pv unmerge devfsd >>> These are the packages that I would unmerge: !!! Trying to unmerge package(s) in system profile. 'sys-fs/devfsd' !!! This could be damaging to your system. sys-fs/devfsd selected: 1.3.25-r8 protected: none omitted: none >>> 'Selected' packages are slated for removal. >>> 'Protected' and 'omitted' packages will not be removed. DreamGate etc #
OK.. I wont bother summarising reasons why... but to answer your question.. Yes devfs is dropped from 2.6.13. And the block is removed. Anyone who is trying to run devfs on 2.6.13+ needs to be shot :)
I think his point is that, just because you're emerging *-sources-2.6.13 doesn't mean that you have to remove devfsd and, if you're testing different kernels, the block isn't convenient. Personally, I'm concerned with his second comment. Having portage whine about uninstalling something that is no longer part of the system package set is confusing, although I realise that this isn't specifically a concern of the kernel herd. I responded to someone who was enquiring about this (they understandably believe portage when it says that it isn't safe) and informed him to ensure that his effective profile was the stock 2005.1 one. Apparently it still raises the same warning. Under those circumstances I don't think portage should make a fuss - it's saying that it's part of the "system profile" but it isn't (even if it was at the time that it was installed). With regard to the kernel/2.6.13 side of things perhaps a warning could be issued to ensure that users are not using stale /etc/make.profile symlinks?
To clarify my previous statement, I meant "if you're testing different kernels and are still choosing to run devfsd with some instances <=2.6.12". In such cases, udev and devfs can co-exist with the appropriate trickery. Mind you, such users probably ought to know how to contend with the strategically placed block too and I daresay that they are not in the majority ;)
(In reply to comment #3) > I think his point is that, just because you're emerging *-sources-2.6.13 doesn't > mean that you have to remove devfsd and, if you're testing different kernels, > the block isn't convenient. > > Personally, I'm concerned with his second comment. Having portage whine about > uninstalling something that is no longer part of the system package set is > confusing, although I realise that this isn't specifically a concern of the > kernel herd. I responded to someone who was enquiring about this (they > understandably believe portage when it says that it isn't safe) and informed him > to ensure that his effective profile was the stock 2005.1 one. Apparently it > still raises the same warning. Under those circumstances I don't think portage > should make a fuss - it's saying that it's part of the "system profile" but it > isn't (even if it was at the time that it was installed). With regard to the > kernel/2.6.13 side of things perhaps a warning could be issued to ensure that > users are not using stale /etc/make.profile symlinks? I changed my /etc/make.profile symlink to point to 2005.1 (was 2005.0) and it still said I was taking a risk. So ... if it's safe to unmerge devfsd I will go ahead. But shouldn't changing the symlink have fixed the complaint?
> But shouldn't changing the symlink have fixed the complaint? Exactly, that was my point. But I believe that that specific issue is a failing of portage which should ultimately be raised with the portage herd rather then the kernel herd (although the matter is obviously relevant within the context of this bug entry).
I'll actually answer both :) I completely understand that they can both co-exist. and I would encourage it for users running 2.6/2.4. The reason the block was in is because the typical migration path is: 2.6.12->2.6.13, and if they used devfs all the time they have had 2.6 installed (since it provides virtual/dev-manager, and that is in the base profile) then it would never actually prompt for udev to be installed. Thats the scenario I want to avoid. Portage throws those warnigns purely based on that virtual. devfs is one of (will be) 3 packages which provide dev-manager. udev is the default in modern profiles but at the end of the day.. the system profile entry is the virtual. If you try and unmerge something which is in the system profile directory, it will warn you. I agree it might be a good idea to check to see if there is another package fulfilling that virtual before it warns about it being a danger.
Ah ... OK ... just for the record, here's how it stands now: DreamGate ~ # emerge -pv unmerge devfsd >>> These are the packages that I would unmerge: !!! Trying to unmerge package(s) in system profile. 'sys-fs/devfsd' !!! This could be damaging to your system. sys-fs/devfsd selected: 1.3.25-r8 protected: none omitted: none >>> 'Selected' packages are slated for removal. >>> 'Protected' and 'omitted' packages will not be removed. DreamGate ~ # ls -l /etc|grep make.profile lrwxrwxrwx 1 root root 49 Oct 6 21:50 make.profile -> ../usr/portage/profiles/default-linux/x86/2005.1/ DreamGate ~ #
(In reply to comment #7) > I completely understand that they can both co-exist. and I would encourage it > for users running 2.6/2.4. It's not reasonably feasible to switch back and forth between 2.4 and 2.6 kernels on one system, really. > The reason the block was in is because the typical migration path is: > 2.6.12->2.6.13, and if they used devfs all the time they have had 2.6 installed > (since it provides virtual/dev-manager, and that is in the base profile) then it > would never actually prompt for udev to be installed. Thats the scenario I want > to avoid. This is actually exactly what happens now after this bug has been fixed (see Bug 108566, comment #2). I'm reopening this bug to see if a better solution can be found; otherwise we honestly have to tell people the truth - devfs in no longer supported w/ 2.6 kernels. As it is now - kernels >=2.6.13 are in fact missing a dependency. I think this is much more important issue than supporting legacy configurations.
I know it's not ideologically clean, but why not add udev (or another virtual, which doesn't contain devfsd) as dependency to new kernels ?
(In reply to comment #9) > (In reply to comment #7) > > I completely understand that they can both co-exist. and I would encourage it > > for users running 2.6/2.4. > > It's not reasonably feasible to switch back and forth between 2.4 and 2.6 > kernels on one system, really. Of course it is. This is completely feasible, and almost a requirement on some archs. Sparc is a good example here. > > The reason the block was in is because the typical migration path is: > > 2.6.12->2.6.13, and if they used devfs all the time they have had 2.6 installed > > (since it provides virtual/dev-manager, and that is in the base profile) then it > > would never actually prompt for udev to be installed. Thats the scenario I want > > to avoid. > > This is actually exactly what happens now after this bug has been fixed (see Bug > 108566, comment #2). I'm reopening this bug to see if a better solution can be > found; otherwise we honestly have to tell people the truth - devfs in no longer > supported w/ 2.6 kernels. As it is now - kernels >=2.6.13 are in fact missing a > dependency. I think this is much more important issue than supporting legacy > configurations. We wouldn't be supporting legacy configurations. I also dont see the point in not telling people "the truth". We can either forcably depend on static-dev and udev, or we can depend on virtual/dev-manager like we do which is the correct way of doing things. Put simply... devfs support is dropped, and people need to stop using it if they want 2.6.13. Explanations and warnings exist in portage and on-online, and for m ost people the system will still boot with the minimal/dev which is supplied anyways. I am closing this bug again, since this has been going on now for some time, and no matter what the outcome there will always be a few unhappy people. If you would like to talk about it further, please catch me on IRC.
Sorry, I meant "legacy configurations will always be supported anyways". The reason the block was originally in-place was to force a sane migration. Bare this in mind... Poeple are installing kernel sources - and not an actual application which is ready to run. Until people compile and isntall this thing, nothing is going to matter. There is absolutely no reason why people wouldnt want to keep 2.6.12 around for a while, until they are comfortable that 2.6.13 is fine to roll with.. and use devfs for the 2.6.12 installation. I could probably go through loads of scenarios here. So hopefully you can see now what I mean by being unableto keep everyone happy anyways.
