On Thu, 2007-12-06 at 13:24 -0500, Bill Nottingham wrote: > 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? The way you get the information now is gconf... but realistically, if it's about saving those changes, it's about persistent changes with the live images and having those also post-install. It's not specifically about trying to use dbus to snake out NM bits. And really, if we get to NM everywhere, we can stop prompting for network bits during the install (except as needed) > > > - 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. The global hammer is "all storage devices". Which is exactly what we'd end up locking otherwise. So it just seems like six of one vs half dozen of the other > > > 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. I think we're talking past each other a bit... and I should make it more clear probably that although there are things with udev/hal that make me ... less than happy, we probably should go that way (at least in the second stage) > > > 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. It's far better to catch an exception and log that there was an error writing out a network config than to crash in the middle of writing it out. > > > > ... 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? Let's move it all to the kernel and be done... > > > > 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. I just don't think that a single stage is going to be of a size that's practical. Even if we were to split all of the language bits out into their own images Jeremy _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
