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