On Mon, 2005-12-19 at 03:33 +0000, Bill Crawford wrote: > Not really ;) we were all hoping you would do it. Boy, that's the type statement that really makes someone want to continue to be an open source volunteer. Sheesh. > But this sounds like the perfect answer to all the "yum wouldn't update > at all because of dependency problem X" mails we see on the list. > Getting as much updated as possible in those circumstances would be > helpful, particularly for people who want to test (whether it be running > rawhide by default, or trying it from -test1 onwards) -- which I realize > isn't the case you want to optimize for, of course :) not really. testers, frankly, should expect problems and be capable of working around them. > One point about breaking up transactions: it would allow e.g. a minimal > install to be done first, thus solving a lot of problems for people who > get halfway through an install and it breaks due to hardware issues, or > network problems if doing a net install, or whatever. You'd pretty much > guarantee that as long as the first (sub?)transaction completed, you'd > have a bootable system, allowing the rest to be fixed up afterwards not necessarily. If something is missing a non-library dep that it requires to boot properly you could still be screwed. For example: new kernel requires a new mkinitrd or a new SysVinit. Someone doesn't notice the new requirement and fails to add the SysVinit >= somever. Then your system won't boot and you're still stuck. So this is definitely not a save-all - it would just diminish the chance. I'm mostly interested in breaking up the transaction for purposes of lowering the memory footprint of large transaction sets. but in all seriousness - if you want these features then you have to work for them. My time is finite and my interest in features I don't use is fleeting. -sv -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list