| Summary: | kernel 2.6.13 wants to remove devfsd | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Honza <hkmaly> |
| Component: | Eclasses | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | jakub, mal, vdmitri, znmeb |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Honza
2005-10-06 16:31:07 UTC
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. |
