>>> Install eselect-news-20070709 into /var/tmp/portage/app-admin/eselect-news-20070709/image/ category app-admin >>> Completed installing eselect-news-20070709 into /var/tmp/portage/app-admin/eselect-news-20070709/image/ * checking 1 files for package collisions existing file /usr/share/eselect/modules/news.eselect is not owned by this package * This package is blocked because it wants to overwrite * files belonging to other packages (see messages above). * If you have no clue what this is all about report it * as a bug for this package on http://bugs.gentoo.org So basically updating from 0.24.1 using emerge -1 paludis doesn't work without disabling collision protection.
eselect-news was (slightly incorrectly) put in PDEPEND to avoid this problem and it wfm: # emerge -a1 paludis [ebuild N ] sys-apps/paludis-0.24.5 USE=(...) [ebuild N ] app-admin/eselect-news-20070709 block is a no-go b/c it makes upgrade path a PITA.
Doesn't work for some reason Portage doesn't pull in eselect-news after paludis: pena tomcat-5.5.23-r5 # emerge -p paludis These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] app-admin/eselect-news-20070709 [ebuild U ] sys-apps/paludis-0.24.5 [0.24.2]
(In reply to comment #2) > Doesn't work for some reason Portage doesn't pull in eselect-news after > paludis: Thats the intended behavior since bug #180045.
(In reply to comment #3) > > Thats the intended behavior since bug #180045. > wouldn't the intended behavior be to install it right after, not right before?
PDEPEND is a type of runtime dependency. They really should be installed as soon as possible. Anyway, it's a mute point because packages that have file collisions are supposed to block each other.
(In reply to comment #5) > PDEPEND is a type of runtime dependency. They really should be installed as > soon as possible. Anyway, it's a mute point because packages that have file > collisions are supposed to block each other. > If it's installed before, I don't see any use for it. Just use a RDEPEND then. The whole point of the variable is to get it installed after it. But indeed the ebuilds should be blocking each other.
I have moved paludis from RDEPEND to DEPEND in eselect-news to force the order.
Shift it back from DEPEND and into RDEPEND, and fix your deps. eselect-news rdeps on *any* version of paludis- this is flat out wrong however, since <0.24.5 triggers a collision. Meaning eselect-news needs >=paludis-0.24.5; set the RDEP to the correct value (regardless of PDEPEND), and the collision isn't possible. Upshot of specifying the dep correctly, eselect-news hits the graph in the appropriate place (because you have the correct deps in it).
(In reply to comment #8) > Shift it back from DEPEND and into RDEPEND, and fix your deps. > eselect-news rdeps on *any* version of paludis- this is flat out wrong however, > since <0.24.5 triggers a collision. Meaning eselect-news needs > >=paludis-0.24.5; set the RDEP to the correct value (regardless of PDEPEND), > and the collision isn't possible. It doesn't require >=0.24.5. It works with any Paludis version. The issue here is that blocking isn't doable, since it would require uninstalling Paludis in order to upgrade it.
(In reply to comment #9) > (In reply to comment #8) > > Shift it back from DEPEND and into RDEPEND, and fix your deps. > > eselect-news rdeps on *any* version of paludis- this is flat out wrong however, > > since <0.24.5 triggers a collision. Meaning eselect-news needs > > >=paludis-0.24.5; set the RDEP to the correct value (regardless of PDEPEND), > > and the collision isn't possible. > > It doesn't require >=0.24.5. It works with any Paludis version. > > The issue here is that blocking isn't doable, since it would require > uninstalling Paludis in order to upgrade it. Dunno, a solution that involves uninstalling paludis doesn't sound horrid to me ;) Meanwhile, yes the code may work with any paludis version. But the ebuild (gentoo packages) doesn't, due to file collisions. Thus either it a blocker needs to be leveled, or the rdeps of eselect-news updated to the range of ebuilds it works with. The latter is simpler- it also has the upshot of stating the *dep correctly (eselect-news needs it as a runtime dep, not a build dep).
As noted above in (Comment #8, Comment #10), this is not fixed (colliding DEPEND). Reopen.
I have added versioned DEPEND, but that's the last time I am favourable for collision-protect users in such a case. Note that it cannot be a RDEPEND b/c it could be pulled before paludis then)
It's still wrong. eselect-news has to be pulled in before Paludis, since it's a dependency. PDEPENDing upon eselect-news is wrong.
(In reply to comment #13) > eselect-news has to be pulled in before Paludis, since it's a > dependency. PDEPENDing upon eselect-news is wrong. How's eselect-news a paludis dependency? It doesn't compile without it? o_O
> How's eselect-news a paludis dependency? It doesn't compile without it? o_O It's a RDEPEND and I am deliberately doing it incorrectly to work around people using collision-protect.
(In reply to comment #15) > It's a RDEPEND and I am deliberately doing it incorrectly to work around people > using collision-protect. Err, let me quote Comment #13: eselect-news has to be pulled in *before* Paludis <-- doesn't sound like RDEPEND? :)
(In reply to comment #14) > (In reply to comment #13) > > eselect-news has to be pulled in before Paludis, since it's a > > dependency. PDEPENDing upon eselect-news is wrong. > > How's eselect-news a paludis dependency? It doesn't compile without it? o_O Paludis requires eselect-news installed in order to run correctly. eselect-news requires Paludis installed in order to run correctly. This means the install order has to be eselect-news, *then* Paludis. This will give a collision for existing Paludis users, but that's unavoidable here, and not a QA issue since it's not a file being owned by multiple packages.
(In reply to comment #17) > This will give a collision for existing Paludis users, but that's unavoidable > here, and not a QA issue since it's not a file being owned by multiple > packages. Hmm? The current news.eselect is owned by <paludis-0.24.5, the new one is owned by eselect-news, sounds for sure like the file is and will be owned by two packages until paludis gets upgraded. So, are you asking for the blocker getting stuck there, or where's this debate heading?
(In reply to comment #17) > Paludis requires eselect-news installed in order to run correctly. eselect-news > requires Paludis installed in order to run correctly. Well, then you have unsolvable circular dependency. > This means the install order has to be eselect-news, *then* Paludis. No, it doesn't. :) It means you'd have to install both simultaneously, which is impossible while they are two separate packages.
(In reply to comment #19) > > This means the install order has to be eselect-news, *then* Paludis. > > No, it doesn't. :) It means you'd have to install both simultaneously, which is > impossible while they are two separate packages. Nope. eselect-news can be installed before Paludis. The only issue there is that there will be a file collision. This is not, however, a problem. Collision detection is there to protect against accidental multiple ownership of files, which is not the case here.
(In reply to comment #20) > Collision detection is there to protect against accidental multiple ownership of files, > which is not the case here. Humpf... if it wasn't the case, then you'd have no collision in the first place (Comment #18). Anyway, this debate clearly isn't getting anywhere.
(In reply to comment #21) > (In reply to comment #20) > > Collision detection is there to protect against accidental multiple ownership of files, > > which is not the case here. > > Humpf... if it wasn't the case, then you'd have no collision in the first place > (Comment #18). That's a temporary collision that's only there until the upgrade is complete. It is not an error, and collision-protect complaining about it is a false positive. The collision-protect feature is there to detect legitimate multiple ownership problems, not to get in the way of upgrading things. > Anyway, this debate clearly isn't getting anywhere. And the ebuilds in the tree are still wrong.
(In reply to comment #22) > That's a temporary collision that's only there until the upgrade is complete. > It is not an error, and collision-protect complaining about it is a false > positive. The collision-protect feature is there to detect legitimate multiple > ownership problems, not to get in the way of upgrading things. Maybe you could attach a 'heuristic' collision-protect patch for portage folks, then? Because how on earth is a package manager supposed to know when a collision is 'legitimate'?! There's no legitimate collision when two different packages claim the exact same file and calling this a 'false positive' doesn't make any sense whatsoever. > And the ebuilds in the tree are still wrong. As noted multiple times above: foo RDEPENDs on bar which RDEPENDs on foo doesn't imply neither that foo should be installed first, nor that bar should be installed first.
(In reply to comment #23) > Maybe you could attach a 'heuristic' collision-protect patch for portage folks, > then? Because how on earth is a package manager supposed to know when a > collision is 'legitimate'?! There's no legitimate collision when two different > packages claim the exact same file and calling this a 'false positive' doesn't > make any sense whatsoever. You misunderstand the feature. It cannot, by its nature, guarantee that any collision it flags is a genuine problem. This is one of the cases where it isn't, so the collision should be ignored. This can be done by not enabling the feature. > > And the ebuilds in the tree are still wrong. > > As noted multiple times above: foo RDEPENDs on bar which RDEPENDs on foo > doesn't imply neither that foo should be installed first, nor that bar should > be installed first. Which is all well and good, but the ebuilds in the tree are still wrong. They need to ensure that eselect-news is installed before Paludis.
I have reverted all the dep changes in the tree and now they RDEPEND on each other and the solution is to disable collision-protect.
(In reply to comment #25) > I have reverted all the dep changes in the tree and now they RDEPEND on each > other and the solution is to disable collision-protect. And this is not a solution. Earlier versions of paludis will still cause a collision- nfc if devrel handbook still is relevant, but do know it's documented as a no no there; long term, it's known-bad to ignore collision-protect. If this were an unlikely occurence, go nuts, but you're suggesting it as part of the default upgrade path- that's not really much of an option, and strikes me as violating QA a fair bit. Basically, stop being stupid and either level the blocker, or tighten the deps; no point pissing around leaving it horked in the interim.
(In reply to comment #26) > (In reply to comment #25) > > I have reverted all the dep changes in the tree and now they RDEPEND on each > > other and the solution is to disable collision-protect. > > And this is not a solution. Earlier versions of paludis will still cause a > collision- nfc if devrel handbook still is relevant, but do know it's > documented as a no no there; long term, it's known-bad to ignore > collision-protect. Collision-protect is there to protect against accidental screwups. This is not an accidental screwup. Collision-protect should therefore be ignored. > If this were an unlikely occurence, go nuts, but you're suggesting it as part > of the default upgrade path- that's not really much of an option, and strikes > me as violating QA a fair bit. It would be a QA violation if multiple packages were each owning the file. That isn't what's happening here; it's an artifact of the upgrade path. > Basically, stop being stupid and either level the blocker, or tighten the deps; > no point pissing around leaving it horked in the interim. Not an option, since it would break the upgrade path.
Created attachment 126007 [details, diff] fix this mess already Geez, what an unproductive debate. See the patch and apply it. - correctly requires >=sys-apps/paludis-0.24.5 unlike the latest 'fix' - no collision - forces eselect-news to be emerged *before* paludis because ciaranm thinks it's the only correct way for some whacky reason, despite the fact that it causes this stupid collision If you dislike the above, then you can stick a blocker there and let users unmerge paludis, I'll be entirely happy with that. :P
Created attachment 126008 [details] ix this mess already for real And now even use pkg_setup() as intended... sigh
Reopen.
Uh, that's a horrible dirty hack. Horrible dirty hacks to work around a bogus collision notice are a very bad thing. It also doesn't solve the problem at hand. (In reply to comment #28) > - forces eselect-news to be emerged *before* paludis because ciaranm thinks > it's the only correct way for some whacky reason, despite the fact that it > causes this stupid collision If you don't know why it's necessary, stop trying to fix things. In fact, if you don't know why eselect-news has to be merged before Paludis, don't say anything at all.
(In reply to comment #31) > Uh, that's a horrible dirty hack. Horrible dirty hacks to work around a bogus > collision notice are a very bad thing. It also doesn't solve the problem at > hand. Then solve the collision properly by sticking a blocker there, as with every other package that installs colliding files. ;) > (In reply to comment #28) > If you don't know why it's necessary, stop trying to fix things. In fact, if > you don't know why eselect-news has to be merged before Paludis, don't say > anything at all. Good thing that the maintainer fixed it - so that now the order will be totally random with the mutual RDEPENDs. Maybe you should either attach a better solution here or keep such advice as the one quoted above outside of this bug. So far the only thing you've produced here was a totally unproductive bickering about 'false positives' and complaining how every solution proposed here is wrong.
(In reply to comment #32) > (In reply to comment #31) > > Uh, that's a horrible dirty hack. Horrible dirty hacks to work around a bogus > > collision notice are a very bad thing. It also doesn't solve the problem at > > hand. > > Then solve the collision properly by sticking a blocker there, as with every > other package that installs colliding files. ;) You know fine well that that isn't a viable solution. And if other people are using blockers for ownership change collisions rather than real collisions, they need to be stopped. > > (In reply to comment #28) > > If you don't know why it's necessary, stop trying to fix things. In fact, if > > you don't know why eselect-news has to be merged before Paludis, don't say > > anything at all. > > Good thing that the maintainer fixed it - so that now the order will be totally > random with the mutual RDEPENDs. Maybe you should either attach a better > solution here or keep such advice as the one quoted above outside of this bug. > So far the only thing you've produced here was a totally unproductive bickering > about 'false positives' and complaining how every solution proposed here is > wrong. Every solution proposed here *is* wrong. Me not providing a different one doesn't change that basic fact. The only difference between solutions that have been provided so far is the impact of their wrongness.
Whether or not you want to fix the collision, the current dependencies are plain wrong: - You explicitely allow to emerge eselect-news with any paludis version, no matter that they will keep overwriting each other's files (re-read Comment #10 and Comment #26). - If you want to have eselect-news installed *before* paludis (reasons for which you've still failed to explain beyond the completely flawed logic in Comment #17) then the current mutual RDEPENDs won't do that either in half of the cases.
Uh huh. Now suggest a solution whose unwanted side-effects are less severe than those of the current situation.
(In reply to comment #35) > Uh huh. Now suggest a solution whose unwanted side-effects are less severe than > those of the current situation. Unwanted side-effects, such as fixing the currently broken dependencies, or which ones exactly?
@peper: you're the maintainer, meaning it's your ass if it violates QA. Kindly chime in and stop this idiocy.
(In reply to comment #36) > (In reply to comment #35) > > Uh huh. Now suggest a solution whose unwanted side-effects are less severe than > > those of the current situation. > > Unwanted side-effects, such as fixing the currently broken dependencies, or > which ones exactly? Any solution you propose has to ensure a) that it is not necessary to uninstall Paludis to perform the upgrade, and b) that eselect-news is installed before Paludis when upgrading Paludis using Paludis. Breaking either of those destroys the upgrade path, so they're completely out. The solution must also not involve adding insane hackery to work around a false positive on a feature that's misfiring in this particular case. (In reply to comment #37) > @peper: you're the maintainer, meaning it's your ass if it violates QA. Kindly > chime in and stop this idiocy. Unfortunately, this whole thing's his fault to begin with...
(In reply to comment #38) > Any solution you propose has to ensure a) that it is not necessary to uninstall > Paludis to perform the upgrade, and b) that eselect-news is installed before > Paludis when upgrading Paludis using Paludis. Breaking either of those destroys > the upgrade path, so they're completely out. All done in the patch above. > The solution must also not involve > adding insane hackery to work around a false positive on a feature that's > misfiring in this particular case. The pkg_setup() hackery is not any more insane that overwriting files installed by one package by different files installed by another package. If you dislike it, feel free to die on collision-protect in FEATURES with <sys-apps/paludis-0.24.5 installed instead - because it will bomb out anyway. $ diff -Nau news.eselect news.eselect-20070709 | wc -l 112 The above is paludis-0.24.2 vs. app-admin/eselect-news-20070709. You claim it's correct to overwrite files with random vastly different versions? That's exactly what will happen on paludis downgrade with the current deps.
(In reply to comment #39) > $ diff -Nau news.eselect news.eselect-20070709 | wc -l > 112 > > The above is paludis-0.24.2 vs. app-admin/eselect-news-20070709. You claim it's > correct to overwrite files with random vastly different versions? That's > exactly what will happen on paludis downgrade with the current deps. It's the same file, updated slightly. The diff is large because a constant has been replaced by a function, which affects a lot of single lines. This is not a case of two different packages providing a file that happens to have the same name but different purposes. So yes, the overwrite is legit.
(In reply to comment #40) > The diff is large because a constant has been replaced by a function, which ... will cause any news stuff in ${ROOT}/var/lib/gentoo/news get ignored on paludis downgrade. :P @peper - So... two solutions have been mentioned above, if you dislike nuking the conflicting file, make eselect-news die on collision-protect in FEATURES, won't make a difference, just will fail gracefully at least. Pick up one, fix the stuff and deps and close this crazy bug already. ;)
OK, lets summarize this: - You decided to keep the dependencies completely wrong and to ignore the collision, because it's 'false positive' and ebuilds are free to overwrite their files with different versions as they wish? Or because paludis doesn't care about collisions at all and users are required to install third-party stuff to get this feature (as Comment #12 suggests)? - You decided to ignore the provided fix that'd make eselect-news installed before paludis as requested in Comment #13, Comment #17 etc. (intentionally ignoring the lack of logic in that request) exactly why? - You decided to close this bug as WONTFIX without any reason provided because... you can't be bothered? - And, for the same reason you decided to ignore the patch provided in Bug 179064 Comment #1 to make eselect-news work with portage? Or was it because paludis oh so rocks that the majority of users that use portage can lick your swamp? The current dependencies are broken, therefore reopening this bug. Also noting here GLEP 42 isn't a paludis-specific one (neither is whatever other GLEP), so making the ebuild depend on paludis despite the provided patch is about as logical as would a dependency on rpm be.
(In reply to comment #42) > OK, lets summarize this: > - You decided to keep the dependencies completely wrong and to ignore the > collision, because it's 'false positive' and ebuilds are free to overwrite > their files with different versions as they wish? Because it's a false positive and a necessary part of a clean upgrade path, yes. > Or because paludis doesn't care about collisions at all and users are > required to install third-party stuff to get this feature (as Comment #12 > suggests)? What, it took you this long to start with the Paludis conspiracy theory accusations? > - You decided to ignore the provided fix that'd make eselect-news installed > before paludis as requested in Comment #13, Comment #17 etc. (intentionally > ignoring the lack of logic in that request) exactly why? Because it's wrong. > - You decided to close this bug as WONTFIX without any reason provided > because... you can't be bothered? Because the current solution is the best that's been proposed. > - And, for the same reason you decided to ignore the patch provided in Bug > 179064 Comment #1 to make eselect-news work with portage? Or was it because > paludis oh so rocks that the majority of users that use portage can lick your > swamp? The patch was against an old version of eselect-news which lacks some of the functionality of newer versions. You are more than welcome to update the patch. > The current dependencies are broken, therefore reopening this bug. Also noting > here GLEP 42 isn't a paludis-specific one (neither is whatever other GLEP), so > making the ebuild depend on paludis despite the provided patch is about as > logical as would a dependency on rpm be. Er, no. Read the code. The current eselect-news implementation requires Paludis. You are welcome to port the current version to Portage if you wish.
(In reply to comment #43) > Because it's wrong. What's exactly wrong there? > Because the current solution is the best that's been proposed. Right, maybe I could even take you seriously if you were able to get consistent with at least half of your comments here (such as Comment #17). The current mutual RDEPENDs won't do that. Plus the unversioned paludis dependency there is flat out wrong as noted above repeatedly - no matter how many times you'll mumble the 'false positives' voodoo here. > The patch was against an old version of eselect-news which lacks some of the > functionality of newer versions. You are more than welcome to update the patch. Yeah, ignoring a patch for two months and then declaring it outdated obviously rocks. :P
(In reply to comment #44) > (In reply to comment #43) > > Because it's wrong. > > What's exactly wrong there? You've already been told. > > Because the current solution is the best that's been proposed. > > Right, maybe I could even take you seriously if you were able to get consistent > with at least half of your comments here (such as Comment #17). The current > mutual RDEPENDs won't do that. Plus the unversioned paludis dependency there is > flat out wrong as noted above repeatedly - no matter how many times you'll > mumble the 'false positives' voodoo here. eselect-news does not require any particular Paludis version. Requiring a particular Paludis version breaks the upgrade path. Until you understand this you should keep quiet.
(In reply to comment #45) > eselect-news does not require any particular Paludis version. Requiring a > particular Paludis version breaks the upgrade path. Until you understand this > you should keep quiet. ZOMG. If you split something out of a package to a separate ebuild, you need to make sure that you'll avoid overwriting the split-out stuff with older bundled versions of the same - that's what the blockers/versions deps are there for. It's so damn obvious that further debates on this topic are a pure waste of time, so please stop this already. Been done so for years in lots of ebuild, yet you paludis folks need to be special apparently and ignore general policies. And no, my patch doesn't break any upgrade path. And no, sticking a _versioned_ dependency (!= blocker) there doesn't break any upgrade path either, just won't avoid the collision on upgrade - but that's still *lot* better than allowing to overwrite stuff with arbitrary old versions as the ebuild does now.
> Yeah, ignoring a patch for two months and then declaring it outdated obviously > rocks. :P News support in portage is only in trunk, so it seems you are barking at the wrong tree. I have working patches for current version of news.eselect, but am waiting for portage release with news support. btw. I don't want to see this bug REOPENED again.
(In reply to comment #46) > (In reply to comment #45) > > eselect-news does not require any particular Paludis version. Requiring a > > particular Paludis version breaks the upgrade path. Until you understand this > > you should keep quiet. > > ZOMG. If you split something out of a package to a separate ebuild, you need to > make sure that you'll avoid overwriting the split-out stuff with older bundled > versions of the same - that's what the blockers/versions deps are there for. Blockers are no good, since they break the upgrade path. > It's so damn obvious that further debates on this topic are a pure waste of > time, so please stop this already. The obvious solution, in this case, is wrong. eselect-news has to be installed before Paludis, and Paludis cannot be uninstalled as part of the upgrade path. > Been done so for years in lots of ebuild, > yet you paludis folks need to be special apparently and ignore general > policies. Because it breaks the upgrade path, yes. This *is* a special case.
(In reply to comment #47) > btw. I don't want to see this bug REOPENED again. So fix the dependencies, they are broken. Still don't get it? Maybe we should CC your mentor then. Oh wait, that's the guy who actually filed this bug. :P
(In reply to comment #48) > Because it breaks the upgrade path, yes. Please stop this trolling. The patch here breaks *nothing*. It actually ensures that eselect-news gets installed *before* paludis as you requested as well (unlike the current RDEPENDs). And as already noted above - if you dislike nuking the old file, they you can as well die on FEATURES=collision-protect instead, it will not make the situation any worse than it is now, at least it will fail gracefully.
(In reply to comment #50) > (In reply to comment #48) > > Because it breaks the upgrade path, yes. > > Please stop this trolling. The patch here breaks *nothing*. It actually ensures > that eselect-news gets installed *before* paludis as you requested as well > (unlike the current RDEPENDs). And as already noted above - if you dislike > nuking the old file, they you can as well die on FEATURES=collision-protect > instead, it will not make the situation any worse than it is now, at least it > will fail gracefully. As you've already been told repeatedly, both your suggestions are nasty hacks that are worse than the way things are currently.
(In reply to comment #51) > As you've already been told repeatedly, both your suggestions are nasty hacks > that are worse than the way things are currently. Obviously, getting the dependencies right and making the ebuild at least die gracefully is lot worse than leaving the dependencies broken and bombing out on collision - everyone can see that. :P Now, if you have nothing useful to add (as you've manifested all over this bug), then please stop commenting.
(In reply to comment #52) > Obviously, getting the dependencies right and making the ebuild at least die > gracefully is lot worse than leaving the dependencies broken and bombing out on > collision - everyone can see that. :P Now, if you have nothing useful to add > (as you've manifested all over this bug), then please stop commenting. If a feature is broken, the solution is not to add in hacks to work around that feature, and the solution is most definitely not to require that users temporarily uninstall critical packages. The way things are currently is as uninelegant as it's going to get.
peper - which part of 'the unversioned depend on paludis in eselect-news ebuild is flat out wrong' did you still miss? Re-assigning this bug to QA.
eselect-news does not require any particular Paludis version.
(In reply to comment #55) > eselect-news does not require any particular Paludis version. You need re-read Comment #8 and Comment #10 a couple of times it seems, as well as http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=5#doc_chap9
(In reply to comment #56) > (In reply to comment #55) > > eselect-news does not require any particular Paludis version. > > You need re-read Comment #8 and Comment #10 a couple of times it seems Faulty logic. Using a fake dependency to force merge order doesn't work since, as you've already been told, it'll result in the wrong install order. > as well as > http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=5#doc_chap9 Er, even if what it says there were not factually incorrect and not applicable to this situation, following that blindly would result in far worse breakage than ignoring it. I quote: > The reason file conflicts are critical is because if "foo" provides the file > /usr/bin/example and "bar" is going to overwrite it, and later "bar" is > unmerged, Portage will remove /usr/bin/example and it is therefore likely it > will break "foo". Since, in this case, foo has a runtime dependency on bar, the scenario discussed does not apply -- unmerging a package's runtime dependencies will break most packages.
Created attachment 126996 [details, diff] Patch for eselect-news ebuild This patch fixes the issue for me and is very simple.
(In reply to comment #58) > Created an attachment (id=126996) [edit] > Patch for eselect-news ebuild > > This patch fixes the issue for me and is very simple. No good, for two reasons already explained in this bug.
(In reply to comment #57) > Faulty logic. Using a fake dependency to force merge order doesn't work since, > as you've already been told, it'll result in the wrong install order. The only wrong install order you get is with *current* broken deps. See the patch attached here for a fix. As already noted here multiple times, allowing to overwrite files with random version provided by another package is clearly broken and not a feature or a fake dependency no matter how much you'd like to claim the opposite just for the pure sake of pissing off people and wasting their time here. This bug takes about one minute to fix, yet we are at almost 60 comments, half of which are your broken scratched record 'arguments'. Ridiculous.
(In reply to comment #59) > (In reply to comment #58) > > Created an attachment (id=126996) [edit] > > Patch for eselect-news ebuild > > > > This patch fixes the issue for me and is very simple. > > No good, for two reasons already explained in this bug. > Then please file bugs for Portage as it must be doing something wrong when this patch works with it.
(In reply to comment #60) > (In reply to comment #57) > > Faulty logic. Using a fake dependency to force merge order doesn't work since, > > as you've already been told, it'll result in the wrong install order. > > The only wrong install order you get is with *current* broken deps. See the > patch attached here for a fix. The patch is not a fix, since Paludis requires eselect-news to be merged first. The patch guarantees that that will not be the case. > As already noted here multiple times, allowing to overwrite files with random > version provided by another package is clearly broken Temporarily, as part of the upgrade path. It isn't a genuine collision. > This bug takes about one minute to fix, yet we are at almost 60 comments, half > of which are your broken scratched record 'arguments'. Ridiculous. We are at 60 comments because you don't have a clue what you're talking about and you won't shut up or learn. Allow me to repeat: eselect-news must be installed before Paludis when using Paludis. Paludis must not be forced to be uninstalled during any part of the upgrade process. Adding in hacks that damage the live filesystem to work around a for-developers feature that's misbehaving is not a viable or sane solution. (In reply to comment #61) > Then please file bugs for Portage as it must be doing something wrong when this > patch works with it. No, you're just not doing good enough testing.
(In reply to comment #62) > The patch is not a fix, since Paludis requires eselect-news to be merged first. And my patch does *exactly* that. You haven't even bothered to try, apparently. Not to mention that you still failed to provide a single reason *why* paludis requires eselect-news to be emerged first. > The patch guarantees that that will not be the case. Nonsense. > Temporarily, as part of the upgrade path. It isn't a genuine collision. Yeah, and when users will downgrade, they are free to overwrite it yet again with random old version of the same because the current dependencies are *wrong*. > eselect-news must be installed before Paludis when using Paludis. Paludis must > not be forced to be uninstalled during any part of the upgrade process. Yeah, both are done by the patch I've attached here ages ago. > Adding in hacks that damage the live filesystem to work around a for-developers > feature that's misbehaving is not a viable or sane solution. Adding a die on collision-protect enabled damages *nothing*. Now, go provide some valid arguments finally, are just stop wasting other people's time.
(In reply to comment #63) > Not to mention that you still failed to provide a single reason *why* paludis > requires eselect-news to be emerged first. ... and since you don't know the answer, despite it being highly obvious and clearly visible, and despite me having already told you, why are you still wasting everyone's time on this bug? Comment #13. Read it. Don't say anything else until you understand it.
(In reply to comment #64) > Comment #13. Read it. Don't say anything else until you understand it. Yeah, wonderful. And now - what the current ebuilds do: # emerge -pv paludis These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] virtual/c++-tr1-type-traits-0 0 kB [ebuild N ] dev-cpp/libebt-1.3.0 USE="-doc -test" 142 kB [ebuild N ] dev-cpp/libwrapiter-1.2.0 USE="-doc" 142 kB [ebuild N ] virtual/c++-tr1-memory-0 0 kB [ebuild N ] virtual/c++-tr1-functional-0 0 kB [ebuild N ] sys-apps/paludis-0.24.5 USE="bash-completion -contrarius -cran -doc -glsa -inquisitio -pink -portage -qa ruby vim-syntax -zsh-completion" 1,368 kB [ebuild N ] app-admin/eselect-news-20070709 6 kB Total: 7 packages (7 new), Size of downloads: 1,656 kB Now, go, take my patch, apply it and retry the above. Once you've done so, come back to comment on this bug.
(In reply to comment #65) > (In reply to comment #64) > > Comment #13. Read it. Don't say anything else until you understand it. > > Yeah, wonderful. And now - what the current ebuilds do: > > # emerge -pv paludis ... using emerge, so it's not an issue which way the cycles are resolved, since emerge doesn't have a runtime dependency upon Paludis.
(In reply to comment #66) > ... using emerge, so it's not an issue which way the cycles are resolved, since > emerge doesn't have a runtime dependency upon Paludis. Geez, of course that using emerge. That's what this whole bug is about (go back to Comment #0). So - may I ask what's the point of your comment above?
(In reply to comment #67) > (In reply to comment #66) > > ... using emerge, so it's not an issue which way the cycles are resolved, since > > emerge doesn't have a runtime dependency upon Paludis. > > Geez, of course that using emerge. That's what this whole bug is about (go back > to Comment #0). So - may I ask what's the point of your comment above? It's exactly the same highly obvious point that explains why a blocker isn't a usable solution. If we only cared about emerge, a blocker forcing an uninstall and reinstall of Paludis would be adequate. Since we don't only care about emerge, the upgrade path using Paludis has to be kept clean too.
(In reply to comment #66) > > ... using emerge, so it's not an issue which way the cycles are resolved, since > emerge doesn't have a runtime dependency upon Paludis. > Well I did test my patch with paludis and it does seem to work there too. It does give you a warning ... When adding package 'app-admin/eselect-news-20070709::gentoo': ... Dropping run dependencies to post dependencies because of exception 'Circular dependency: Atom '>=sys-apps/paludis-0.24.5' matched by merge list entry 'sys-apps/paludis-0.24.5::gentoo', which does not yet have its dependencies installed' (paludis::CircularDependencyError) but it's not fatal As such my patch should be adequate for paludis users too
> (In reply to comment #66) > It does give you a warning That warning is significant. If anything, Paludis should be changed to have an explicit hard DEPEND to avoid allowing that resolution as a fallback, since that fallback being chosen will lead to breakage.
(In reply to comment #70) > > (In reply to comment #66) > > It does give you a warning > > That warning is significant. If anything, Paludis should be changed to have an > explicit hard DEPEND to avoid allowing that resolution as a fallback, since > that fallback being chosen will lead to breakage. > Care to elaborate on how it is significant? The update works and after that it's gone.
(In reply to comment #68) > the upgrade path using Paludis has to be kept clean too. Yeah, and could you show us how does my patch break the paludis upgrade path? It doesn't, and doesn't cause the stupid circular dependency shown above in Comment #69 either. RDEPEND <-> RDEPEND is a broken solution, shown above multiple times.
(In reply to comment #71) > Care to elaborate on how it is significant? The update works and after that > it's gone. Paludis contains code that calls eselect-news when Paludis is executed. Thus, when Paludis is the package manager, eselect-news needs to be available before Paludis can be invoked.
(In reply to comment #73) > > Paludis contains code that calls eselect-news when Paludis is executed. Thus, > when Paludis is the package manager, eselect-news needs to be available before > Paludis can be invoked. > That's why paludis has an RDEPEND on eselect-news?
(In reply to comment #74) > That's why paludis has an RDEPEND on eselect-news? It's currently an RDEPEND because a cycle breaking solution that messes up the ordering is only really messy and to be avoided if at all possible, not completely unviable.
(In reply to comment #75) > (In reply to comment #74) > > That's why paludis has an RDEPEND on eselect-news? > > It's currently an RDEPEND because a cycle breaking solution that messes up the > ordering is only really messy and to be avoided if at all possible, not > completely unviable. > I don't still see any reason on why the order would matter as long as the command line interface doesn't change (which no-one has so far argued here so I presume it hasn't happened). If paludis ./configure would check for eselect-news then it would of course be a different ball game but that only happens in trunk.
(In reply to comment #75) > It's currently an RDEPEND because a cycle breaking solution that messes up the > ordering is only really messy and to be avoided if at all possible, not > completely unviable. So - how about that you apply a solution that actually *works* and *ensures* the correct order instead of this academic blurb which doesn't go anywhere? If you need eselect-news before paludis, then paludis needs to DEPEND on app-admin/eselect-news and app-admin/eselect-news needs to PDEPEND on >=sys-apps/paludis-0.24.5, instead of producing circular RDEPENDs that clearly don't work just anywhere.
(In reply to comment #76) > I don't still see any reason on why the order would matter as long as the > command line interface doesn't change (which no-one has so far argued here so I > presume it hasn't happened). If paludis ./configure would check for > eselect-news then it would of course be a different ball game but that only > happens in trunk. The configure check's there for a reason, and that reason applies to 0.24.5 as well as trunk...
(In reply to comment #78) > > The configure check's there for a reason, and that reason applies to 0.24.5 as > well as trunk... > And maybe you care to share that reason? Instead of polluting bugzilla with these kind of comments maybe you could give the reasons straight away without asking.
(In reply to comment #79) > (In reply to comment #78) > > The configure check's there for a reason, and that reason applies to 0.24.5 as > > well as trunk... > > > > And maybe you care to share that reason? Instead of polluting bugzilla with > these kind of comments maybe you could give the reasons straight away without > asking. I've given the reason several times already. It's a dependency.
(In reply to comment #80) > > I've given the reason several times already. It's a dependency. > Yes and as such it's fine to check for it but it really doesn't matter whether eselect-news is installed before or after the package (of course the latter can't be checked in configure) and as such as long as the ebuild takes care of making sure it is installed everything is fine. So nothing in that argument prevents my patch from being committed.
(In reply to comment #81) > (In reply to comment #80) > > > > I've given the reason several times already. It's a dependency. > > > > Yes and as such it's fine to check for it but it really doesn't matter whether > eselect-news is installed before or after the package If Paludis is being used to upgrade Paludis, it matters, since Paludis requires eselect-news to be installed as soon as Paludis can be invoked.
(In reply to comment #82) > If Paludis is being used to upgrade Paludis, it matters, since Paludis requires > eselect-news to be installed as soon as Paludis can be invoked. And when you upgrade to paludis-0.24.5 using paludis, the (bundled) eselect-news thing is already there because you've installed it with paludis. So, what's this debate about?
(In reply to comment #83) > (In reply to comment #82) > > If Paludis is being used to upgrade Paludis, it matters, since Paludis requires > > eselect-news to be installed as soon as Paludis can be invoked. > > And when you upgrade to paludis-0.24.5 using paludis, the (bundled) > eselect-news thing is already there because you've installed it with paludis. Wrong again. If eselect-news hasn't been installed, the bundled version is removed as part of the upgrade, leaving a time when eselect news is invoked but not installed. > So, what's this debate about? Things are much more complicated than you've been assuming throughout...
(In reply to comment #84) > Wrong again. If eselect-news hasn't been installed, the bundled version is > removed as part of the upgrade, leaving a time when eselect news is invoked but > not installed. Well, maybe you should redesign your package manager so that it doesn't break when some totally noncritical piece of bash script is not installed. What would you be invoking it for in-between emerging two packages in a row that depend on each other? This eselect-news thing is not intended to spit out any output during compile/emerge at all.
(In reply to comment #85) > Well, maybe you should redesign your package manager so that it doesn't break > when some totally noncritical piece of bash script is not installed. It doesn't break. It yells loudly. > What would you be invoking it for in-between emerging two packages in a row > that depend on each other? This eselect-news thing is not intended to spit > out any output during compile/emerge at all. Paludis supports arbitrary actions at arbitrary phases.
(In reply to comment #86) > It doesn't break. It yells loudly. So let it yell or mute it, I could really care less. Invoking eselect-news until installing the whole chain of packages is finished doesn't make any sense.
Can we please fix this now? Two things that install the same file have to block each other. Its really that simple. I don't care to hear any arguments otherwise on this bug, go bring it to somewhere like gentoo-dev@ where discussions are supposed to happen. If you think this is somehow a "false" collision (whatever that means) please file a bug with the portage team explaining what that means, and how we can fix it. Thanks
(In reply to comment #88) > Can we please fix this now? Two things that install the same file have to > block each other. Its really that simple. Wrong. Two packages falsely owning the same file need to block each other. One file moving ownership from one package to another doesn't require a block, since adding a block will really hurt the upgrade path.
(In reply to comment #89) > since adding a block will really hurt the upgrade path. No it won't hurt upgrade path in any way, if it does, then your package manager is broken so go and fix it; re-read Comment #87. Move the debate elsewhere as requested in Comment #88 or file a bug about collision-protect handling, you are repeating yourself with arguments that have been dismissed as non-issue ages ago - just for the sake of having an ill-reasoned 'excuse' for not fixing a clearly broken dependencies in your ebuilds.
(In reply to comment #90) > Move the debate elsewhere as requested in Comment #88 or file a bug about > collision-protect handling, you are repeating yourself with arguments that have > been dismissed as non-issue ages ago - just for the sake of having an > ill-reasoned 'excuse' for not fixing a clearly broken dependencies in your > ebuilds. collision-protect is designed to protect OSX from ebuild clobbering OSX-installed files. Using that to screw up upgrade paths is not a viable option.
(In reply to comment #91) > collision-protect is designed to protect OSX from ebuild clobbering > OSX-installed files. Using that to screw up upgrade paths is not a viable > option. You completely failed to explain how does a blocker screw your upgrade paths (except for the bogus argument about paludis yelling loudly when eselect-news is not yet there no matter than it will be installed right after paludis). This yelling is apparently very useful for the very common cases when some smart user hooks an eselect-news call to src_unpack or does similar smart actions. If you have many such users, I'd suggest educating thim to fix their misconfiguration/misuse of package manager hooks, instead of having a broken dependency tree for every else who is able to use package managers properly. If you are not happy with current policies and current collision-protect handling, go file a bug instead of arguing how many angels would fit on a top of a needle here, it's getting highly annoying and unproductive.
As it happens, all the above discussion is irrelevant to 0.26.0_alpha5 anyway, since it's now a hard dep...
(In reply to comment #93) > As it happens, all the above discussion is irrelevant to 0.26.0_alpha5 anyway, > since it's now a hard dep... Really don't get you I'm afraid. It's been a hard dep ever since 0.24.5 in the ebuild...
Well why're you still going on about eselect news in src_unpack? How about eselect news in src_test, which is exactly what happens?
(In reply to comment #95) > Well why're you still going on about eselect news in src_unpack? How about > eselect news in src_test, which is exactly what happens? See... - Why don't you stop playing these stupid riddle games and don't answer a simple question directly instead? - Or why don't you stop putting words into my mouth (I'm not *still* going about src_unpack, that was an *example* of retarded hooks usage, could as easily have been src_compile or whichever other nonsensical phase) instead? - Or yet better why don't you avoid the need to ask such question by posting a clear, non-ambiguous comment in the first place instead? (All of the above has been suggested on gentoo mailing lists and on numerous bugs before many many times yet you fail to learn altogether.) Are you telling us that you've deliberately made src_test fail when eselect-news is not installed to avoid the need to fix your screwed dependencies? Congratulations, you've taken the definition of ridiculous to a completely new level.
IMHO we should just close this bug as paludis users should by now have moved to later versions. I did look into this at one point and didn't come up with a solution that would satisfy both Paludis and Portage users 100% (Ciaramn does have technically valid points about the upgrade path but at the time of testing this did not cause a problem in practise).
Paludis includes test cases for as much functionality as we can. This is a good way of reducing bugs -- most bugs occur in code that isn't covered by test cases. Since there's been at least one silly bug in a supplied hook script, we've taken to adding test cases for them.
