Gentoo Portage and Unneeded Blocking

It is my experience that Gentoo sometimes blocks on packages for which there really is no need. I've had this discussion with some people in IRC (#chat on irc.up.ac.za):

<jkroon> modular X is freaking me out. <wian> nah <jkroon> i must unmerge xorg-x11 before i can build the new one ... :( <jkroon> which may or may not work. <wian> post_max_size = 10M <derick> jkroon: as long as you don't open new apps :) <wian> XD <jkroon> yea --- LordVampiro is now known as Dragonite <jkroon> derick, but, this is something portage _should_ be able to handle. I'm going to install a new xorg-x11 (>= 7.0), so why should a <7.0 (which is going to be _unmerged_ during the upgrade) block stuff that can't work with it installed. <jkroon> apt can handle that correctly, (even though rpm can't, the last time i checked) <derick> because the old xorg would only get unmerged after the new one <HeatZync> i wonder what it could be then <jkroon> derick, yea and ... ? <jkroon> there is no reason why you can't compile 7.0 with 6.9 installed, then install 7.0 and then uninstall 6.9. <derick> and the new modular packages are going to overwrite the old xorg's files - hence the blocking <jkroon> so? portage keeps an md5 database of installed files and _only_ removes them if they haven't changed in any case. <littlefire> jkroon: i followed instructions on http://gentoo-wiki.com/HOWTO_Modular_Xorg and it worked fine <jkroon> so having the files clobbered during that particular upgrade isn't a problem. <wian> 'De-installing' just sounds wrong <jkroon> indeed. <wian> :-\ <derick> if there's no reason why portage shouldn't remove after install, then why would it do so? --> nuclearjoker (johndoe@ethereal-6D7A73D1.telkomadsl.co.za) has joined #chat <derick> there has to be a reason <jkroon> i'm missing you're point. <jkroon> i'm missing your point. <derick> sorry, I meant "why wouldn't it" <jkroon> the unmerge algorithm goes something like this: <jkroon> for each file in package xorg-x11-6.9 do: <jkroon> if md5(file) == correct_md5: <jkroon> unlink(file) <derick> nm, forget that --> caine (grey@ethereal-EEE7AEAF.up.ac.za) has joined #chat <jkroon> meaning that if during the installation of xorg-x11-7.0 some file gets nuked that belongs to 6.9 then unmerging 6.9 won't kill 7.0 <jkroon> yes, 6.9 and 7.0 can't live on the same machine but surely we can ensure that 6.9 gets unmerged directly after 7.0 got merged? <derick> not necessarily <Dragonite> yo Mirabilis <-- caine (grey@ethereal-EEE7AEAF.up.ac.za) has left #chat <derick> you can't guarantee that merge+unnmerge is atomic <jkroon> well, for that matter, you can't guarantee that merge is atomic, so the machine is in a broken state either way. <jkroon> the unmerging of 6.9 doesn't need to be atomic, it's simply there to clean up any orphan files. <derick> # Collision protect will scream bloody murder if we install over old versions <derick> RDEPEND="!<=x11-base/xorg-x11-6.9" <derick> there you have it <jkroon> yes, but that is my point. portage should also check what will get _unmerged_ during the emerge process before screaming bloody murder. <-- djjkotze has quit (Quit: Leaving) --> djjkotze (djjkotze@ethereal-C71AF052.cs.up.ac.za) has joined #chat --- ChanServ gives channel operator status to djjkotze <jkroon> djjkotze, make up your mind. <wian> mind? <jkroon> forgot - he doesn't have one :p <Mirabilis> Don't worry, he doesn't mind <wian> how droll <Mirabilis> That wasn't droll at all <wian> oh, forgive me... my sacasm flag wasnt set. <jkroon> cause my 7.0 merge just failed ... <wian> narf <derick> jkroon: in this case it can't do that because the files that belongs to the old xorg now belong to packages with other names <wian> ati screen card? <wian> fg <wian> ergh <jkroon> wian: yes, ATi plagues me once more. <wian> :) <wian> wel, at least you <jkroon> derick, no why? <wian> 'll be able to use xorg-server-1.1.0 <wian> mmmmebbe <wian> :) <jkroon> by the _end_ of the merge process xorg-x11-6.9 will be gone, so anything that conflicts with that _should_not_ flag a block. <derick> collision protect makes sure that packages with different names don't overwrite each other's files <jkroon> it does that for packages with the same name as well. <derick> and in this case it does <derick> no <jkroon> o.O <derick> they get overwritten when you install <jkroon> yes, and then the old version _goes_ away. <derick> config files get collision protected <jkroon> unless things are SLOTed. <derick> for packages with the same name <jkroon> in which case SLOTs are handled as if they are seperate packages? <derick> there is no collision protection for other files when you install the same package, otherwise they could not be replaced <nuclearjoker> jkroon, dit you make a package - backup of 6.9 ? <jkroon> nuclearjoker, no. <jkroon> i already fixed the problem and the merge is going on. <nuclearjoker> I see you problem. <nuclearjoker> your <nuclearjoker> oh, good then <derick> slotted packages install in different locations <jkroon> yes, but my point stand: there is no reason (ignoring reasons imposed by portage) why you have to first unmerge 6.9 before compiling and merging 7.0 <-- Dragonite has quit (Quit: done) <Mirabilis> I can think of a reason <Mirabilis> But it doesn't make sense without a flamingo <derick> jkroon: well, while emerging one of modular xorg's deps, that particular merge cannot know that xorg 6.9 is going to get unmerged at the end of they day, meaning that it should not enforce collision protection <Mirabilis> Or...a flamenco! <Mirabilis> Ola! <derick> only the actual xorg-x11-7.0 knows that xorg-x11-6.9 is going to get unmerged <jkroon> derick, yes it can. portage can even before it _starts_ doing anything (aka: when calculating what it is going to merge) also calculate what is going to get unmerged. <derick> yes, but that information is not passed on to the individual packages' emerges <derick> otherwise you'd have to get a list of every file that's going to get unmerged to all your dependencies <jkroon> it doesn't need to. the "blocking" that prevents this is done during the dependancy calculation phase when this information _will_ be available if it's calculated at that time instead of after things has been merged. <gary> lol I just had an autoconf-wrapper issue :) <jkroon> no, you don't need that file list. <gary> aclocal was failing <gary> man gentoo is freaking amazing :) <gary> I love it <derick> then as simeon says, "send them the patches" <jkroon> i'd first like to discuss it with the portage developers. there may be something else that i'm not aware of. <derick> you could try it out by removing that block depend and setting CONFIG_PROTECT_MASK=/ <derick> but collision protect would probably still bitch <jkroon> no, by _only_ removing the collision. config files should still remain protected. <jkroon> to be updated with etc-update at a later stage. <derick> ah, just remove collision-protect from your FEATURES <derick> jkroon: following that reasoning, lots of other things wouldn't have to block either <derick> e.g. packages that have been obsoleted and are replaced by new (different) ones <jkroon> indeed. <jkroon> no, in that case they should still block unless the old package gets unmerged automatically. <derick> that in itself is something that's lacking <jkroon> yes, and if that gets implemented then yes what I said here will apply equally.

Well, I may well be missing something here and it doesn't bother me just quite enough yet to do something more than simply rant about it.