Jeremy Katz (katzj@xxxxxxxxxx) said: > > - writes network configs that have no bearing on what the system is > > actually using at the time > > This is because we're spastic about how we want to deal with the > network, not because of HAL vs not. If we'd actually settle on one way > of doing network configuration, then this would be a non-issue You're going to pull any NM configuration that's been done into the installed system without using HAL and dbus? > > - has to run under a global lock so that it doesn't trigger the media > > automounter > > This doesn't really change that -- we're still going to want to avoid > triggering the automounter because the automounter has no concept of > mounting a system into a chroot. No, but you can do it in a more sane manner than the global hammer. > > - requires setting deprecated kernel options > > Which ones? CONFIG_SYSFS_DEPRECATED, at least. > > This is... good? Really? > > I'm not saying it's good... I'm just saying that I don't think that we > magically fix anything with the live install case purely by switching Not *purely* by switching, but it enables you to have a more sane framework for addressing these issues. Heck, you could then start sharing the CD code between pirut, yum, anaconda, or actually use the system media code for handling CDs. You could use dbus to handle migrating keyring information between live and installed systems. It allows you to tie into more systems without having to do all the code yourself. > > Frankly, I'm confused by the fact that we don't want to use the system > > hardware library because of a possible rewrite at some point in the > > future, and yet we're perfectly happy to redo the installer to talk to > > the parted bindings of the month twice a year. > > Huh? We haven't changed parted bindings that we use since we started > using parted 6.5 years ago. pyparted is what msw had imported into > parted and then I split it out into a separate source to be more > maintainable 3.5 years ago. Maybe I'm confusing it with something else. > > Abstractions for our abstractions? Brilliant! > > > > More seriously, there is a python-ish binding for HAL, but using the > > straight dbus interface seems simpler from a dependency standpoint, and > > it's shorter code. > > I guess that realistically, I'd be less inclined to want an abstraction > over a real python binding. But directly talking to dbus ends up making > things looking very much not like python and more difficult to read. > Not to mention that you end up needing to wrap essentially _any_ dbus > call in a try/except for a DBusException because otherwise you can and > do get them in unexpected places. That's the unfortunate lesson that > the CD support in pirut has taught me :( There are only so many exceptions you logically want to handle, though - if the daemon isn't there or isn't responding, it's logically no different than some command not existing in the install image, or parted crashing, etc. > > > ... maybe not the best day to try to convince me that udev is a good > > > idea as I wrestle with the fact that livecds have stopped booting > > > because udev apparently doesn't want to create device nodes anymore ;) > > > > *shrug*. Not sure why you'd *want* to maintain a giant stack of NIH, and > > special cases for the wacky controllers of the future, and... > > Luckily, wacky controllers seem to be becoming less common. Well, > except for on ppc :-) Yes, but still - why maintain that in two places instead of one? Why require every new device type to have to change two pieces of code? > > > From a POV of debuggability, the smaller approach with less moving parts > > > feels like it's going to fit in better and be less of a hassle. Also, > > > including udev+hal in stage1 is going to lead to a substantial increase > > > in the size. Even though we're changing some of how we download images, > > > the split is still pretty important because a 50 meg initramfs is kind > > > of painful. > > > > Somehow I suspect 50MB isn't quite what it would end up being. And udev's > > already there (see above.) > > 50MB is more if we were to not have a split stage1/stage2 anymore, not > just udev+hal in the first stage. > > But I guess that's probably inevitable and I'm likely the main one who'd > be cranky about it... would be good to get some other opinions on which > way is better. I just have been burned a few too many times by udev > (and to a lesser degree hal, just because less is "dependent" on it) to > be really happy with depending on them The nice thing about moving to a single stage is it allows to fix a lot of the warts with how it's constructed. That being said, it might be a multiple-release process. Bill _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
